workflow (was Re: RFD: Kernel release numbering)

[Jeff Garzik]

Other ideas <thinking out loud>...

I maintain my netdev-2.6 queue by creating a ton of "subject-specific" 
repositories locally,

> 8139cp/     bonding/  ieee80211/    mips/     sis900/    typhoon/
> 8139too/    e1000/    ixgb/         misc/     skge/      viro-iomap/
> 8139too-2/  ham/      janitor/      mv643xx/  sk_mca/    viro-iomap-orinoco/
> ALL/        ibmlana/  kill-iphase/  pcnet32/  smc91x/    viro-isa-ectomy/
> atmel/      ibmtr/    mii/          s2io/     sundance/  wifi/

and I pull all of these into a master repository netdev-2.6 (locally 
'ALL').  netdev-2.6, in turn, gets pulled into -mm when Andrew makes a 
new release.  When I am ready to push something upstream, I pull one or 
more repositories into my net-drivers-2.6 queue, which is essentially my 
"push to upstream" queue.

This scheme allows me to cherry-pick fixes and features.  If a critical 
fix comes along, it doesn't have to wait for the other less-critical 309 
changesets to go.


We could have a linus-pending-2.6 queue, managed by Linus, that 
functions in a similar manner to my netdev-2.6:

a) Have a monthly or weekly official release.  Could be automated, but 
probably not.

b) snapshots of linus-pending-2.6 function as a development tree, taking 
over some of the current -mm purpose...  -mm is just too massive and 
multi-purpose at this point

c) locally [or publicly?], Linus sorts patches and 'bk pulls' into 
specific repositories, as I do with netdev-2.6.  "sata", "sata-fixes", 
"net drivers", "net drivers - janitorial", etc. could be potential pull 
queues from me to Linus.

d) When features/fixes are ready to move from linus-pending-2.6 to 
linux-2.6 repository, Linus just does a pull+push locally.  Fixes would 
likely go immediately into linux-2.6, unless it needs staging in 
linus-pending-2.6 first.  Potentially destabilizing stuff stays longer 
in linus-pending-2.6.

Thus, Linus controls the patch flow (and stability/features) simply by 
choosing when to pull stuff from the on-going dev tree that he manages.

e) Andrew continues doing what he's been doing:  merging tons of 
patches, staging big features, etc.


So what does this accomplish, besides increasing the complexity of 
Linus's work?  What's the point?

1) Creates a structure to enable linux-2.6 to be the on-going stable 
tree, by creating an official on-going dev tree.

2) Release early, release often.  The proposal that started this thread 
does the opposite: it slows things down.

3) Makes it easier to manage the flow of changesets.

4) Takes pressure off -mm to be "everything under the sun."  Users are 
far more likely to test a tree that is blessed with Holy Penguin Pee, 
and builds on all architectures.  And this in turn gives -mm more freedom.

	Jeff, trying to think outside the box



-
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/