[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how quickly do PA-RISC patches make it to mainstream kernel?



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


Reply to: