lkml.org 
[lkml]   [2005]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFD: Kernel release numbering

>-rc just means "please start testing", not "deploy me on your corporate
>database server".
>
>
Does it? Where on www.kernel.org does it say that?


Since people's trust was lost (a bit) when the -rc convention was
"embraced and extended", it seems like it would be a good idea to
_explicitly publish_ (and promote) the definitions (when they are agreed).

I am assuming that the problem is still essentially:
"We need more testers"

And that one objective of this discussion is actually to clarify how the
numbering scheme presents the risks and rewards associated with running
a particular kernel? (yes, you're also sorting out development workflow
but that's another issue)


Since the "show us the code" principle applies, I'm trying to draft some
text that I propose linking to from a prominent place on www.kernel.org
(yes it may be hosted elsewhere)

My gut-feel working title was : "Our Promises To The Linux Kernel
Community" - but I think that's going to be wrong :)

Here's the very very draft text - I've barely proof read it and I've not
researched the process so I know it's not expressed well.
It's the kind of thing I'd want to read to assess which kernels to test
- hell, right now it's not even obvious if you _want_ me to test them.

--------------------------------------

Background
The 'vanilla' linux kernel produced by Linus et al isn't for everyone.
Many, indeed most, users should be using the kernel that comes with
their distribution (Debian, Fedora etc)
However, if _everyone_ did that then no-one would find the problems with
the kernel - the 'many eyes' part of the FOSS community is essential -
and you can be an active part of it!

This document aims to describe how people of different skill and
experience levels can help.
Be warned - it can be hard work - but that's what makes it worthwhile.

The Problem
The kernel developers let you grab hold of a kernel tree at any time -
which one should you use?

The key to all this is in the numbering; it indicates what stage of
development that particular version of the kernel is at now.
Broadly the way it works is this(?):
* Developers send code and fixes to maintainers who have their own tree
* Maintainers keep an eye on the code quality and send it through to
Linus when they think it's ready
* Linus holds the main, stable(ish) tree
* Distributions take a stable-ish tree and may apply their own changes
and back-port bugs to try and get a very stable tree

Kernel Numbering
The kernel numbering usually looks like: 2.6.10; The X.Y.Z should be
read as:
* X and Y indicate the main and sub versions of the kernel - probably
'2.6' for quite a while yet.
* The Z indicates incremental 'releases' that the kernel community
(Linus) think are OK to use in most 'production' environments.

But the beauty (and complexity) of the linux kernel is that you get to
see it whilst it's putting its make-up on!!

Applying the Make-up - Developer Kernels
There are lots of developers who have their own 'bk' trees of the kernel
that have changes applied from minute to minute.
Eventually the changes in these trees settle down a bit and elements of
the trees are pulled into a major maintainers tree (eg -mm, Andrew
Morton's tree - more later)
Finally they're pulled into Linus' tree.

-pre Kernels
After a bit Linus feels that there have been quite a few changes and
decides to get everyone back on the same page so he releases 2.6.x-pre1.
This is a developers release.
It won't be announced on linux-kernel-announce.
It will have bugs but it should compile cleanly and shouldn't corrupt
your data (unless noted). It's very useful if you're helping to test
some new hardware or feature and you don't mind if the machine crashes
(maybe a lot - and maybe kills your data too!).
The cycle repeats through -pre2, -pre3 etc until Linus feels that it's
time to think about a new proper release. During these cycles,
developers can add new features and things that used to work may break.

So he takes the last -preN release and re-releases it as -rc1 ... a
Release Candidate.

-rc Kernels
At this point he's saying that he'd _like_ to release it so it won't
corrupt your data and the developers can't find any obvious bugs (unless
noted) but there *will* be some 'cos it's not been tested on every
machine on the planet!
This is a testing release.
It will be announced on linux-kernel-announce.
You should be able to run it on normal hardware without crashes or any
other problems. But you're part of the test team so there is a risk.
This cycle repeats through -rc2, -rc3 etc. During these cycles, _NO_ new
features will be added. Only bugs will be fixed and it should be very
rare for something that worked in -rcX to fail in -rcX+1.
When the bug reports stop appearing it's time for a release.
Linus will take the last -rcN and re-release it as 2.6.x (possibly with
some errata of known bugs)

2.6.x.y Kernels
But it doesn't stop there :)
There may still be unknown bugs because no-one's tested a particular
combination of components that triggers them.
So if a fix for a simple bug is discovered a group of people will review
it and, if it's deemed to be very safe they will apply it to the 2.6.x
and release 2.6.x.1 (or patches or whatever - yet to be agreed AFAICS)
It will be announced on linux-kernel-announce.

Wait, There's More...
Remember about the maintainers kernels? -mm and the like?
Well there's a list of them <here - where?> which explains how to get
them and what their 'manifesto' is.
For the more sophisticated of you out there it may be worth trying out
the -mm kernel (or a friend); they follows the same basic lines as
Linus' - (in a sense they're based on them - but they are the leading
edge of the linux kernel and have extra features and performance
tweaks). They are often more experimental (and risky) than Linus' kernel
though some strive to be more stable - read the manifesto to find out more.
They will be announced on their own lists (see manifesto)


So What To Do?
Join in - run the latest kernel and report back bugs - the kernel
community _do_ want your help.
Just make sure you understand the risks and protect yourself appropriately.


To be continued... (mention kernelnewbies or other links, automating the
process, ketchup etc - thanks Horst, Jan Dittmer, Andrew James Wade)


David
PS To be clear, I'm contributing this text in case anyone feels they can
use it in any way.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.178 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site