Len Brown <[email protected]> wrote:
>
> ...
> Also, I would think Bitmover would be interested in having you enabled
> to keep people like me as happy paying customers.
hm. I guess I can continue to use bk until the end of July or until we hit
the 65535th cset. After that things become murky.
> The question for bk use is what do we do for a reference "Linus tree"
> history. It would be most effective if we could have a single bk history
> rather than everybody rolling their own.
yes, someone needs to set up a bk tree which is fed diffs from Linus's git
tree. Let's call this the linus-git-bk-tree. You then pull this into the
acpi tree.
> > - How do I do a bk `gcapatch' is there is no Linus bk tree to base it off?
> >
> > - If none of the above, which maintainers will put up-to-date raw patches
> > in places where Andrew can get at them?
>
> I can do this if you require it.
Once you have the linus-git-bk-tree, then yes, it would be very nice if you
(or someone else) were to set up another machine which every six hours or
so does
cd bk-acpi/
bk pull bk://linux-acpi.bkbits.net/to-akpm
gcapatch > /ftp-dir/bk-acpi.patch
and makes /ftp-dir available. The same machine could also publish all the
other bk trees, such as Tony's
http://lia64.bkbits.net/linux-ia64-test-2.6.12. I have all the bk url's.
The fact that some developers change the bk URL between major kernel
releases will be a bit of a pain.
> The current "acpi patch" includes
> 68 patches: 200 files changed, 7780 insertions(+), 5455 deletions(-)
>
> Everything in it is intended to go to Linus on day-one of 2.6.13.
> Some of it should really go into 2.6.12 - but frankly, I hesitate
> to touch 2.6.12 while the tools are in such flux.
"flux". I've never seen it spelled that way before ;)
> > I don't know how all this will pan out. I guess the next -mm won't have
> > many subsystem trees and I'll gradually add them as things get sorted out.
>
> Please do not roll -mm without including the ACPI sub-system.
> -mm provides the broadest pre-integration test coverage we've ever had.
> It has allowed us to significantly reduce regressions in Linus' tree
> as we encounter the inevitable setbacks associated with making
> the ACPI sub-system in Linux the best in the industry.
OK, well once we have linus-git-bk-tree I can continue to do bk pulls until
either the bk license explodes or we hit the 65536-csets problem.
After that, the automated-patch-exports thing above would be needed.
In the very short-term, please email me the patch. Some automated daily
thing would suit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]