On Sat, 5 Mar 2005, Jeff Garzik wrote:
Yup, BK could definitely handle that...
However, it's also true that the thing BK is _worst_ at is cherry-picking things, and having a collection of stuff where somebody may end up vetoing one patch and saying "remove that one".
In general, I agree. Andrew and I mentioned this to BitMover recently [though its certainly not a new comment], when they asked us why I had to occasionally blow away the netdev-2.6 tree, and reconstitute it from scratch.
I love BK, but what BK does well is merging and maintaining trees full of good stuff. What BK sucks at is experimental stuff where you don't know whether something should be eventually used or not.
I use BitKeeper to maintain such a tree, "libata-dev". Most stuff in there will go upstream. Some stuff may never go upstream. Some stuff needs to simmer for a while before going upstream. So "change streams" get divided up locally:
[EMAIL PROTECTED] libata-dev]$ ls -FC adma/ atapi-enable/ janitor/ remove-one-fix/ adma-mwi/ bridge-detect/ passthru/ sata-sil-irq/ ahci-msi/ chs-support/ pdc2027x/ tf-cleanup/ ahci-tf-read/ ioctl-get-identity/ pdc20619/ via-6421/ iomap/ promise-sata-pata/
and then I cherrypick from that.
netdev-2.6 queue is maintained the same way. It's simply a merge tree composed of 40+ individual trees, all merged together.
Jeff
- 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/
