Re: stable? quality assurance?

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Martin Steigerwald wrote:
> I think main problem is that the current development process does not give 
> time for quality work and bug fixing.

This has little to do with process.

Put simply, the paid developers work on what they are paid for.  The
volunteers work on what they are interested in.

If you feel that too little work is spent on stabilization and bug fixing, pay
someone or take matters into your own hand.  I.e. report bugs and work with
the developers to get the bugs fixed.

The current development process OTOH gives plenty of time for quality work and
bug fixing:

  - There are several stages at which new code can be tested:
    When it lives in subsystem development trees,
    when it has been pulled into the linux-next tree,
    when it has been pulled into Linus' tree.

  - Bug fixes are pulled by Linus almost any time whenever they are ready.
    (Of course, since fixes can and do introduce regressions too, only
    critical fixes are accepted in later -rcs.)

  - New code submissions are pulled by Linus in a fairly reliable cycle
    with reasonable frequency (less than three months).  That way,
    developers know that if their stuff did not quite cut it for
    mainline merge in month N, they know they can try again in month
    N+2 or N+3.  They are not left to guess whether their next chance
    will be in half a year or two years or next week.  Hence, nobody
    needs to panic and rush things when a merge window draws near.
    Plus, the code and the repository are open, so anybody can ship
    features to customers at any time independently of Linus' release
    cycle.  Linux distributors do this all the time.

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

Most of the maintainers are responsible enough to put only stuff into
linux-next which belongs there, i.e. tested, release-ready stuff.  Likewise
with submissions to Linus during the merge window.

Only some maintainers do in fact try to submit rushed, untested crap.
Sometimes they get caught red-handed.

The release-ready submissions that come via responsible maintainers still
contain some regressions though.  This is inevitable.  There are less
regressions if there are more enthusiasts who test development trees and
linux-next.  There are less regressions in Linus' releases if there are more
enthusiasts who test -rc kernels.  (And submit good bug reports and work with
the developers on them.)  And vice versa.

Process does not do much to prevent bugs or fix bugs.  People do. :-)

However, you can hardly tell people to implement less features and fix more
bugs if they don't owe you anything.
-- 
Stefan Richter
-=====-==-=- =--= --=--
http://arcgraph.de/sr/