Re: RFD: Kernel release numbering

[Russell King]

On Wed, Mar 02, 2005 at 07:10:47PM -0800, Randy.Dunlap wrote:
> Dave Jones wrote:
> > For it to truly be a stable kernel, the only patches I'd expect to
> > drivers would be ones fixing blindingly obvious bugs. No cleanups.
> > No new functionality. I'd even question new hardware support if it
> > wasn't just a PCI ID addition.
> 
> Maybe I don't understand?  Is someone expecting distro
> quality/stability from kernel.org kernels?
> I don't, but maybe I'm one of those minorities.

Don't say that too loudly or else the embedded people will use it as
another excuse not to move on to 2.6 kernels.

But yes, _I_ do expect a certain amount of quality and stability from
kernel.org kernels mainly because there _isn't_ a distro to do that
for us on ARM.  It's fine in x86 land where there are such things and
you have One Single Platform(tm), but in ARM land where there's
numerious platforms, there's very little sense in having a "distro"
maintained kernel.

For instance, I'd like to upgrade the kernel on the main ARM server
here from 2.4 to 2.6, but since it requires a number of subsystems to
work properly (MD, Promise IDE, Ext3, NFS server) which you normally
wouldn't see on ARM embedded systems, I'm not entirely happy to throw
a 2.6 kernel on it just yet.

However, coupled with the requirement for quality, some in the ARM
community expect a certain amount of development to be going on, since
ARM is a relatively fast moving community [*].  Freezing stuff for 6
months isn't really practical when you have support for new platforms
or new drivers wanting to be merged all the time.  Ignoring these
things for 6 months causes someone to spawn a new tree and that's
usually the last you see of any contribution from that direction.

So, what I think we need is for core system, subsystem and "service"
development to slow down a little while still allowing peripheral
low-impact "new stuff" to be added during a "stablisation" period.
We also need to qualify what we mean by "stable in relation to the
resulting kernel - eg, I don't think we should call the "new stuff"
merged during that time "stable".

This actually brings up an interesting point - if new machine support
is stablised external to the "stable" tree, and then merged into that
tree, should it be marked as "experimental"?  Given the previous
paragraph, I think the answer is "yes" since this will allow people
to distinguish the recently merged stuff.



[*] - depends how you understand "fast".  My method of working new
features into the ARM code in Linus' kernel is via a series of small
steps (or a series of smaller series of steps) spread out over a
period of time.

An example of this is the ARM SMP merging, where the low level entry
code has had to be rewritten.  However, rather than just replace the
file, it's getting a series of clean ups first which are aimed in the
direction we want to go.  We're getting towards the state where the
_major_ difference between todays implementation and the SMP version
is the code in a small number of macros, rather than virtually every
line in the file.  However, I do feel like I'm going against the grain
when Linus says "slow down" and I'm seen to be doing cleanup after
cleanup with no obvious effect or point.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/