Re: [ath9k-devel] [ 00/78] 3.3.2-stable review

[Willy Tarreau]

On Sat, Apr 14, 2012 at 01:53:22AM +0300, Felipe Contreras wrote:
> No, I don't want the latest fixes, I want the latest *stable* kernel.

You have it, it's 3.3.2.

> v3.3 is stable, v3.4-rcx are not.

v3.3 *aims to be stable*. That's the big difference. A kernel starts
unstable and converges to something more stable over the time. 2.4 was
still experiencing minor issues that we didn't have in 2.6 when I did
the last release. There were even some security issues we decided not
to fix and to document instead. Still for its users it was considered
much more stable than 2.6 or 3.x.

> v3.4 would take months to cook,
> there will be several release candidates, and it won't be released
> until the known issues decrease to a reasonable level.
> 
> v3.3.x on the other hand are *not* stable.

Nobody said they *are* stable as per the definition of this word.
"stable" is the name of the branch which defines the longterm goal
which is achieved as releases are issued. It's the same with longterm
kernels. They try to maintain even less bugs and try to to introduce
new ones, eventhough this happens from time to time, development is
not an exact science.

> They contain patches
> backported from v3.4, but nobody guarantees they will work. There was
> no v3.3.1-rc1,

Few people test rc, and not all bugs or regressions can be detected by
just a build and a boot.

> so the first time the patches compromising v3.3.1 were
> generally tested together is in v3.3.1, at which point if somebody
> finds issues, it's too late; bad patches are *not* going to be removed
> in v3.3.2.

They would have been if the issue was specific to the backport, which it
was not.

> Once a tag is made, all the patches in it are dependent on
> the pace of the development of mainline (v3.4-rcx), which is
> definitely not stable, specially in the first release candidates.
> 
> IOW, the "stable" branch tries to be stable up to a point, then, it
> becomes a testing ground for mainline, and a tracking device for
> certain mainline issues.

No it's the opposite, it tries to be stable past one point. It's well
known that first stable releases still have a number of bugs, and it's
the reason why Greg takes time to maintain multiple branches in parallel.
Please stop playing the fool, everybody understands this and you make it
appear like bugs are put in stable on purpose, your reasoning really does
not make sense.

Please fork the kernel and maintain your own "morestable" branch, it will
be useful, really, because it will mean that whatever you have in your
branch that is not in stable has to be fixed in mainline, so it will hold
the information Linus wants not to lose. This is a lot of work but you'll
get it done without asking anyone else to do it. I'm not kidding, I'd
probably use it if it's maintained long enough.

Willy

--
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/