lkml.org 
[lkml]   [2010]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: stable? quality assurance?
From
Date
Sorry, forgot Cc again.

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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2010-09-04 18:45    [W:0.038 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site