lkml.org 
[lkml]   [2009]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Large amount of scsi-sgpool objects
    From
    Date
    On Tue, 2009-03-03 at 22:44 +0100, Ingo Molnar wrote:
    > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
    > > > > So the real question is why does the -rt tree even have
    > > > > patches not in the vanilla SCSI tree? This type of cockup
    > > > > clearly demonstrates why it's a bad idea.
    > > >
    > > > Believe me, i have better things to do than to track down your
    > > > regressions. I applied a fix/test patch sent to me by SCSI
    > > > folks.
    > >
    > > Look, I've no problem with you collecting random patches. I
    > > have a problem when you start pushing random SCSI patches into
    > > other trees. [...]
    >
    > Both -tip and -rt are generic trees and there's a connection
    > between them that the maintainers of both are one and the same
    > set of people.
    >
    > So i'm not sure on what grounds you purport to be able to
    > prevent fixes from flowing from -tip into -rt and vice versa.
    >
    > You have no monopoly on the propagation and testing of SCSI
    > fixes. We picked up a v1 patch from the SCSI list and did not
    > add nor remove anything from it.

    OK, let me try and make the problem simpler for you: If you pick up
    random patches outside of your area and apply them without any quality
    control (like code inspections, or even understanding how the patches
    work) you've created a suspect and quality compromised tree. This is
    fine for your own work and others to test and report back (although the
    list will start to see your bug reports as correspondingly lower quality
    if you have a high proportion of self induced failures like this one).

    However, if you base a feature tree off this compromised tree, now
    you're causing extra work for other maintainers who see problems
    reported with this tree, and have to take the time to investigate what's
    going on.

    Worse, supposing there is a genuine SCSI bug exposed by the -rt tree
    (say something timing or interrupt related). So I ask the reporter to
    retry with the regular kernel tree and the bug goes away. Now everyone
    will think "Oh, it's just because of some SCSI crap Ingo put in his
    tree". Result: the bug goes undiagnosed until it bites several people
    in the field, which is an avoidable result.

    The executive summary is that your "it works for me, so I'm putting it
    in my tree" attitude is damaging our quality process.

    James




    \
     
     \ /
      Last update: 2009-03-03 23:43    [W:0.024 / U:32.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site