[lkml]   [1999]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PATCH 2.3.23 pre 2 compile fixes
    On Wed, 20 Oct 1999, David S. Miller wrote:

    > Let me give you two situations to show you why this is true:
    > situation 1) You fix a bug today, you send Linus just that small
    > change to one specific driver, to fix that bug.

    That's almost never the case.

    For drivers that support many cards I usually have ten different
    modifications outstanding, each one to attempt to fix a specific reported
    problem. Most changes either don't fix the problem, or are known to cause
    other problems. It's often a week or two before a test versions is
    reported on, so many times there is no way to serialize the changes.

    I usually have a extensively tested stable version, with "try this fix on
    v0.91" branches, a tested semi-stable version, also with branches ("v0.91u
    crashes? See fi this hacked v0.91g-ppc version works"), and an barely-test
    has-every-enhancement version.

    > This change is fine and nobody complains of breakage.
    > You run through this process about 3 or 4 times.

    50 times.

    > On the 5th change, again small and specific and
    > incremental, Linus and others note that people begin to
    > complain of problems. These people also proclaim that
    > before this 5th change went in things were perfectly fine
    > for them.

    I always discount isolated reports. How many times have you heard "the
    older kernels didn't sig-11 with gcc". I get "your latest driver version
    stopped working" (when no version could have worked with their bad routes or
    mis-paired cross-over cable).

    > situation 2) You spend 4 months, and fix dozens of bugs, and also
    > have reworked major sections of code in a driver to
    > support new cards, or do whatever. You send one big
    > fat patch to Linus after this 4 month period, many
    > users complain that the driver suddenly stops working
    > for them in a big way.

    During that time I annouce the updates to the driver mailing list, make many
    test versions available, and test the driver myself. I have well over 100
    cards, and a handfull of machines.

    > In situation #1 Linus needs only to back out patch #5 or seek a remedy
    > from you for that specific change, the fixes in patches 1 through 4

    And the driver code would never be cleaned up, or reworked because a new
    chip changed things.

    > Now can you see why your "external from the main tree for months"
    > development process sucks and causes grief for everyone?

    The "only add patches to the latest kernel" approach means that people have
    to update to a usually-broken kernel to get a undated board revision to t

    Donald Becker
    Scyld Computing Corporation, and

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.025 / U:60.992 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site