Re: Linux 2.6.12-rc3
From: Andrew Morton
Date: Tue Apr 26 2005 - 00:53:48 EST
Len Brown <len.brown@xxxxxxxxx> 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
> > - 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
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/