[lkml]   [2010]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: stable? quality assurance?
    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
    -=====-==-=- =--= --=--

     \ /
      Last update: 2010-09-04 21:27    [W:0.023 / U:185.776 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site