lkml.org 
[lkml]   [1999]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH 2.3.23 pre 2 compile fixes


A driver bug only affects users that use some particular hardware. So,
backing out an apparently broken patch is not as critical as a kernel bug
that may affect all systems.

My opinion is that a driver bug should not be backed out, given maintainer
being known to be a serious guy, unless the maintainer agrees with, or ask
for that. Anyway, a bug must be fixed and delaying it a long time is a bad
option, in my opinion.

Note, that if it ever appears that the maintainer did the wrong thing, I
trust him to understand how he has been wrong and change the way it will
deliver changes for further updates. A maintainer that did waste time of
users because he delivered broken stuff when this could be avoided is
normally extremally sorry of that, and I am sure Donald has been so if
this happened with some of his driver versions.

Just donnot backout Donald's patches that seems broken and I bet you that
everything will be just fine, or at least not worse that other breakages
that sometimes occur during kernel development.

That's my opinion.

Gérard.


On Wed, 20 Oct 1999, David S. Miller wrote:

> Date: Wed, 20 Oct 1999 15:21:38 -0400 (EDT)
> From: Donald Becker <becker@cesdis1.gsfc.nasa.gov>
>
> I've done it in a way that minimizes the your workload, and makes
> the updates and new drivers immediately available to those with
> stable kernels.
>
> As Linus has described, and what you seem to have problems
> understanding, is that _this_ very technique _maximizes_ Linus's
> workload.
>
> This seems to be the source of your confusion. Batching up sets of
> fixes over a long (ie. not timely) period of time, and then sending
> them all at once for integration is about the worst thing you can do.
>
> 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.
>
> This change is fine and nobody complains of breakage.
> You run through this process about 3 or 4 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.
>
> 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.
>
> 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
> are not backed out and not lost. Whereas in situation #2 he has to
> back the whole thing out, and all the work is gone until things are
> remedied, and you'll probably repeat the cycle as other bugs are found
> whilst you keep resubmitting this huge patch, and eventually Linus
> (like right now) will get disgusted with the whole mess.
>
> Now can you see why your "external from the main tree for months"
> development process sucks and causes grief for everyone?
>
> Later,
> David S. Miller
> davem@redhat.com
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site