![]() | |||||||||||
Messages in this thread
|
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 [from the cache] ©2003-2008 | |||||||||||