why not the latest kernel

StolenNomenclature · 2006-02-16 04:19:05

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:

Snowman · 2006-02-16 05:01:16

It's because the 2.6.16 rc3 kernel is not considered stable (it's a release candidate). It is still being tested and may contain unknown bugs. The latest stable kernel is 2.6.15.4 and it's the version in the Arch repo. The current/extra repo only have stable versions of packages (no alpha, beta or rc). Stability is very important especially when it comes with the kernel. However, if you love your system to be bleeding edge, feel free to make your own 2.6.16-rc3 kernel package.

ozar · 2006-02-16 05:24:46

Yeah, throwing the "rc" kernels into current would be a bit too bleeding edge for me. :shock:

iBertus · 2006-02-16 08:38:44

Maybe such things need to be posted on AUR?

iphitus · 2006-02-16 08:49:45

StolenNomenclature wrote:

Can someone explain to me the rational behind which kernel makes it into the repo?
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?

Might need to read up on the kernel development process buddy!

The RCs have MORE bugs and are generally LESS stable than a vanilla release.

Currently, the way it works, is that new things, that are to be added to the next release, are to be included in the first, and in some odd cases the second rc. The next few RCs are testing, bug fixing, and any relevant changes.

iphitus

StolenNomenclature · 2006-02-16 10:28:33

The first kernel release in the testing (odd numbered) series was 2.6.15-1, followed subsequently by 2.6.15-2, 2.6.15-3 and 2.6.15-4.

When the kernel is considered highly stable, then the odd numbered testing series is changed to the even numbered release candidate series, and thus we have had kernels 2.6.16-rc1, 2.6.16-rc2 and now 2.6.16-rc3.

So the entire series I believe is 2.6.15-1, 2.6.15-2, 2.6.15-3, 2.6.15-4, 2.6.16-rc1, 2.6.16-rc2, 2.6.16-rc3.

I believe that Noodle installed 2.6.15-1 and that just recently a pacman upgrade I performed installed the next version, 2.6.15-2.

I assume the upgrade to the newer kernel was done for the reason that being a later version kernel, it was more stable than the previous version. On this assumption, one would presume that the 2.6.15-3 version is even more stable than 2.6.15-2, and that version -4 more so than -3, and so on.

Yet you seem to be saying that the high quality release candidate version 3 of the kernel series, five versions further on, is actually LESS stable than 2-6.15-2. And by definition that version 2.6.15-3 is also less stable than 2.6.15-2 (since the upgrade was from -1 to -2, not -1 to -3.

In fact the only logical deduction is that since kernel -2, the series had been going progressively downhill in terms of reliability.

If 2.6.15-4 was not better than 2.6.15-1, then why was it made into a release candidate?

I am sorry, but that makes no sense to me at all.

iphitus · 2006-02-16 10:46:59

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

pikass · 2006-02-16 11:12:41

In fact Linus changed the versioning system. There wont be any odd numbered development releases (like 2.3) anymore. That's why many people stuck with the 2.4 series because they dont want to use a kernel branch which is under heavy development

StolenNomenclature · 2006-02-16 20:35:46

iphitus wrote:

no no no no!
<snip>
iphitus

Ok. I got the odd numbered part wrong - it is the second digit not the third. That invalidates my ideas re the 2.6.16 rc3 kernel, but not the 2.6.15-4 (unless I have misunderstood you).

I still cannot understand why we went from the -1 tot he -2 kernel, rather than jump to the -4.

Thanks,

:?:

jaboua · 2006-02-16 20:40:14

The newest version is 2.6.15.4-2

AFAIK, that means that it's the second package made for kernel 2.6.15.4. Correct e if I'm wrong.

ozar · 2006-02-16 21:03:04

jaboua wrote:

The newest version is 2.6.15.4-2
AFAIK, that means that it's the second package made for kernel 2.6.15.4. Correct e if I'm wrong.

Yes, that's correct. The latest kernel is 2.6.15.4 and the -2 is the second Arch version of the kernel to go into the repos.

iphitus · 2006-02-16 22:23:50

Oops, my bad

iphitus

Arch Linux

#1 2006-02-16 04:19:05

why not the latest kernel

#2 2006-02-16 05:01:16

Re: why not the latest kernel

#3 2006-02-16 05:24:46

Re: why not the latest kernel

#4 2006-02-16 08:38:44

Re: why not the latest kernel

#5 2006-02-16 08:49:45

Re: why not the latest kernel

#6 2006-02-16 10:28:33

Re: why not the latest kernel

#7 2006-02-16 10:46:59

Re: why not the latest kernel

#8 2006-02-16 11:12:41

Re: why not the latest kernel

#9 2006-02-16 20:35:46

Re: why not the latest kernel

#10 2006-02-16 20:40:14

Re: why not the latest kernel

#11 2006-02-16 21:03:04

Re: why not the latest kernel

#12 2006-02-16 22:23:50

Re: why not the latest kernel

Board footer