Why not the latest kernel

Question

Can someone explain to me the rational behind which kernel makes it into the repo?
Just recently I believe there was an upgrade from 2.6.15-1 to 2.6.15-2. I cannot understand why not move direct to 2.6.16 rc3?
Surely in a testing branch of the kernel (or any other software product) the later versions should have less bugs, no? Of course there are exceptions to this, but surely as a general rule that is true. So why is the 2.6.16 rc3 not a more desireable transition than 2.6.15-2? It would surely be more stable, no?
Thanks!
:oops:

Answer 1

no no no no!
the kernel is versioned as follows.
a.b.x(.y)(-rcX)
eg, 2.6.15.4, 2.6.16-rc2, 2.5.22
The kernel is considered very unstable when b is an odd number, thus, 2.3, 2.5.
The 2.6 kernel is not going to split to 2.7 in the near future, as it was done for  2.4 and 2.6. This is for the simple reason that there are no changes warranting a major overhaul, and the current system, with experimental things going into apkm's -mm patchset is working well.
Consider each x release to be stable, if it is not an rc, and the b is even.
After a b release, eg 2.6.15, there are y releases, and x plus 1-rc number (a.b.x+1-rcX). So currently, 2.6.16-rcX, 16 is one more than 15, swap X with the latest release candidate release number, releases, The idea is simply that it is a release candidate series, for 2.6.16. In the past, later release candidates have been re-released as the final version. For example, 2.6.15-rc7, was considered stable enough to be released as 2.6.15, and was released as such with only a small handful of changes.
Remember, rc and y releases are independent of each other and occur in parallel. One refines the current stable version, 2.6.15, and the other begins work on an unstable release candidate of the next version.
The 2.6.16-rc1 release, usually occurs 1-2 weeks after 2.6.15. In those two weeks, all major changes are to be made, thus allowing the rest of the rc's rc2 to whichever rc is needed, to be used for bug fixing. Few big patches are allowed in after those 1-2 weeks.
y patches, are to follow the following guidelines, quote kernel/Documentation/stable_kernel/rules
- It must be obviously correct and tested.
- It can not bigger than 100 lines, with context.
- It must fix only one thing.
- It must fix a real bug that bothers people (not a, "This could be a
   problem..." type thing.)
- It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
   security issue, or some "oh, that's not good" issue.  In short,
   something critical.
They are released after 2.6.15 as well, and were created so security and other important patches could be attained quicker, without people having to wait for the whole 2.6.16 release candidate series to complete.
.y generally contains fixes that slip through, critical security updates and other things that fit all the criterion in the file listed above.
arch's packages, are versioned, a.b.x-y, so 2.6.15.4, the latest .y, would be 2.6.15-4.
phew.. hope i didnt confuse you... and sorry for the mathematical approach, but thats how my brain works
iphitus