lkml.org 
[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectworkflow (was Re: RFD: Kernel release numbering)
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@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.442 / U:2.132 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site