Message-Id: <201009041839.09261.Martin@lichtvoll.de>
Date:	Sat, 4 Sep 2010 18:38:59 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	linux-kernel@...r.kernel.org
Subject: Re: stable? quality assurance?

Am Sonntag 11 Juli 2010 schrieb Willy Tarreau:
> Hi Martin,

Hi Willy, hi everyone else reading this,

> On Sun, Jul 11, 2010 at 04:51:42PM +0200, Martin Steigerwald wrote:
> > I hope that someone answers who actually can take some critique. From
> > the  current replies I perceive a lack of that ability.
> 
> well, I'll try to do then :-)
> 
> There were some threads in the past about kernel releases quality,
> where Linus explained why it could not be completely black or white.
> 
> Among the things he explained, I remember that one of primary concern
> was the inability to slow down development. I mean, if he waits 2 more
> weeks for things to stabilize, then there will be two more weeks of
> crap^H^H^H^Hdevelopment merged in next merge window, so in fact this
> will just shift dates and not quality.

During bisecting [Bug 16376] random - possibly Radeon DRM KMS related 
freezes, which goes very slowly due to having lots of unbootable kernels 
with an ext4 / readahead related backtrace during boot, I had an idea:

I think main problem is that the current development process does not give 
time for quality work and bug fixing. As I understand it currently its just 
a constant development of new features with bug fixing and quality work 
having to be done beneath that development:

- before 2.6.36 is released developers aim at developing new stuff for 
2.6.37.

- after 2.6.36 is released developers aim at getting as much stuff into 
2.6.37 and then after two weeks at developing new features for 2.6.38.

This process does not take bug fixing into account at all, cause after the 
merge window has closing, developers hurry to get the stuff ready for the 
next window.

In that model extending the freeze period after rc1 doesn't help at all, 
cause as you say more "crap^H^H^H^Hdevelopment" gets collected for the 
next kernel.

But is that a *given* that no one actually has any influence to? Is 
collecting changes for next kernel like rain that either pours down or not 
- usually pours down in this case like in August in Germany ;)? Who feeds 
Linus with new stuff during the merge window? From what I understand of the 
Linux development process its mainly the subsystem maintainers and Andrew 
Morton.

What if those people stop collecting new stuff for Linus except bugfixes 
about two or three weeks before the next kernel is relased? This would 
give the subsystem trees and the mm tree some time to stabilize a bit, so 
that Linus gets more quality stuff in the first time. And more importantly, 
since developers know that subsystem maintainers and Andrew only collect 
bugfixes 2-3 weeks before the release of a stable kernel, they can as well 
spend some time on quality work.

Of course, developers can still decide: Well if 2.6.37 work is closed 
already and continue developing for 2.6.38 even earlier, but I still think 
this would help to slow things down a bit prior to the critical phase 
before releasing a stable kernel. Cause when I know my subsystem 
maintainer or Andrew won't be taking my stuff anyway, before the release 
kernel is released, I can take a little time for other things.

The main idea here is to have a two-staged freeze process and to 
distribute the "I am only taking bug fixes" work to more people than Linus.

For this to work properly, I think at the time of the release of the 
stable kernel subsystem maintainers and Andrew should branch their trees. 
For example when 2.6.36 is released:

- tree 
  => 2.6.36-stable-tree
  => tree, where 2.6.37 stuff will be going in

Thus when subsystem maintainers take new stuff during the merge window, it 
will be for the next kernel release already, not for the current one. 
Except bugfix work. Whereas I think the criteria for bug fix work should not 
be that strict than for the stable patches Greg collects.

Thus it needs to be clear: No new stuff for next kernel already two weeks 
prior to release the current stable kernel.

I think, this could help. Its a bit like the two-staged development 
process of Debian, but with the freeze period for "unstable" being a fixed 
time interval of about 2 weeks instead of RC=0 for stable ;). Its a bit of 
a formal shift of attention to the stable kernel about 2 weeks before its 
release. Developers might find creative ways to circumvent it, or they 
understand, that this process serves a purpose of improving kernel 
quality.

When you think these two weeks cannot be squeezed into the three-monthly 
development cycle, a four-monthly development cycle might do. But actually 
I don't see why these two weeks could not be made to fit in there.

Installing and testing next kernel after yet another mail to this thread,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists