lkml.org 
[lkml]   [2005]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.11.1
Linus Torvalds wrote:
>
> 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:

[jgarzik@pretzel 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.132 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site