On Thu, 2003-12-04 14:21:03 +0200, Martin-�ric Racine <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > 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 [EMAIL PROTECTED] . +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));
signature.asc
Description: Digital signature
