On Thu, 2003-12-04 14:21:03 +0200, Martin-Éric Racine <q-funk@pp.fishpool.fi> wrote in message <[🔎] Pine.LNX.4.21.0312041417350.2434-100000@hal.pp.fishpool.fi>: > On Tue, 2 Dec 2003, Randolph Chung wrote: > > > On average, how far behind is the PA-RISC integration in the mainstream kernel? > > > For instance, when can I expect 2.4.22-pa17 to have been merged by upstream? > > > Will that show up in the 2.4.23 mainstream vanilla kernel, or only in 2.4.24? > > > > Never, probably. Most of the kernel developers are concentrated on 2.6. > > There's not a lot of interest to merge 2.4 stuff upstream. Besides, there > > are some hacks in the pa tree that cannot be merged upstream anyway. > > While I understand all the excitement for 2.6, I really find it disturbing to > hear that upstream completely disregards integration of non-x86 work into 2.4. Well, I've spoken to a lot of non-ia32 developers, partially directly to what you would call "port maintainers". Just to give an overview: - Very limit base of testers and coders -> port may be broken for quite some time (don't try SMP on sparc32 with 2.6.x). - Arch maintainers are ofently not spending their daytime's job time to maintain their respective architecture. That is, each time Linus accepts a feature that breaks other archs, they need some time to catch up (you can count core developers for eg. Cris or VAX with one hand, even after cutting off one finger or another...) - Bitkeeper vs. patches vs. CVS vs. homegrown systems: they're all horribly incompatible (in manner of a fast workflow). That slows down catching up with Linus' changes, too. (Everybody except those with BK suffer from this. The arch core developers using BK are well off (-> Dave S. Miller, just to name one), they typically get their work merged in a timely manner.) - Doubled work (maintaining 2.4.x while doing active development) slows down development. Eg. the MIPS folks keep up-to-date with boths trees (in their CVS repo), but others just started to focus on the development branch. - Some arch's core developers don't have/take the time to (at least) sync their work to Linus' 2.6.x. So large patch sets queue up which are a PITA to sync. Linus wants to see small patches, so you need to do some extra work doing surgery to your mega-patch. However, this is a problem with two faces: not syncing creates new work (splitting), but there are additionally different philosophies around for actually _how_ to sync up: - You get shot if you send patches while this hasn't explicitely requested by the port maintainer (eg. MIPS). - You are welcome to do the sync work (sounds like parisc folks are interested :-> To draw some conclusions: - We ***need*** some good tools to manage sources. That is, the kernel developers should use all the same tools. But that's a political item so you'll get a hard time to convince the people to use CVS *or* Arch *or* Bitkeeper *or*. em, something else... - Some archs/machines are just dieing out: eg. m68k/Atari won't most probably work neither with 2.4.x nor with 2.6.x. OTOH some new archs only have the development branch in a promising state (VAX :-) However, I think the emphasis is on the SCM thingie. This is currently a really hindering factor. I've even thought about writing a force-replicating filesystem with write logging. If you push a change into a (commonly distributed) tree, it'll *instantly* show up at all cloned trees of all people who work on the same tree. You can't stuff in data *at all* if it can't be patched into a different's people working tree. (So that's in theory CVS with instantly-forced update plus full rollback on conflict.) It's a security nightmare, but I think this "Wiki style kernel development" could really speed up things. However, Linus would loose some control:~| MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Attachment:
signature.asc
Description: Digital signature