> > - architecture xxx doesn't compile
> > there's a few of these now in bugzilla, and personally I don't think
> > they belong there. Any arch other than i386 is always going to be
> > playing catchup, and is nearly always out of date in mainline.
> Quite a few of those are from me. It is a real pity that we keep the
> view of everything other than i386 is playing catch up - that really
> deminishes the usefulness of Linux in a lot of fields.
This was something that was brought up in a discussion at the kernel
summit by (I think) Paul Mackerras. The question was how to make
sure we get all arch's in sync before doing a release.
It should be fairly straightforward thing to do for 2.6.x releases,
but during 2.5.x when stuff is changing so rapidly, it doesn't make
sense to hold up the majority of users just so the other archs can
play catch up.
> Don't forget that ia64, x86-64 and s390 are all potentially growing
> users of Linux.
ia64 and x86-64 maybe, but s390 is way out of the pricerange of most
Linux users. Those who can afford it will likely use distro kernels anyway
due to the added support they paid for.
x86-64 usually isn't that far from mainline (though there was a period
a while ago, where Linus hadn't merged for a while). As most of that
is shared with i386 or very similar, I think when these become more
mainstream, we'll start seeing a lot more people contributing to this,
so it should remain current in mainline also, as long as Andi scales 8-)
> Linux on ARM, MIPS and PPC also has a healthy band of
> productive (commercial and home) users.
Russell has done a great job at keeping ARM up to date in 2.5,
as have the PPC folks. For the most part, the archs aren't that
out of sync. (Insert comedy remark here about m68k being more
up to date than alpha).
> I don't expect that all the other architectures will be as well tested
> as x86; but at least we should know the state of each architecture and
> preferably have 2.6.x (or whatever it gets called) to basically work on
> as many architectures as possible.
indeed. this should be addressed by the time we get to stable releases.
One possibility someone came up with at the summit was just a slightly
different take on the existing pre/rc release model.
The initial pre's remain as they are now, later pres are for strict
bug-fixes and arch resyncs, then the release candidates roll out.
It doesn't sound that impossible a plan, as long as whoever ends up
doing it is strict enough not to include 'just one more feature'
during the arch-merge pre's.
-- | Dave Jones. http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/