lkml.org 
[lkml]   [2005]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.15-rc6: known regressions in the kernel Bugzilla
    On 12/23/05, Andrew Morton <akpm@osdl.org> wrote:
    > Michael Krufky <mkrufky@gmail.com> wrote:
    > >
    > > On 12/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
    > > > Andrew Morton wrote:
    > > > > Adrian Bunk <bunk@stusta.de> wrote:
    > > > >
    > > > >>not a post-2.6.14 regression
    > > > >>
    > > > >
    > > > >
    > > > > Well yeah. But that doesn't mean thse things have lower priority that
    > > > > post-2.6.14 regressions.
    > > > >
    > > > > I understand what you're doing here, but we should in general concentrate
    > > > > upon the most severe bugs rather than upon the most recent..
    > > >
    > > > Hypocratic oath: "First, do no harm."
    > > >
    > > > If a new kernel version can't make things *better*, at least it
    > > > shouldn't make them *worse*. New features are good, performance
    > > > improvements are good, breaking working systems with an update is not good.
    > > >
    > > > I'm with Adrian on this, if you want people to test and report with -rc
    > > > kernels, then there should be some urgency to addressing the reported
    > > > problems.
    > >
    > > I agree. Quite frankly, I am extremely surprised that this matter is
    > > even up for discussion. Is it really so important to release 2.6.15
    > > before the end of 2005 that we dont even have the time to fix
    > > regressions that have already been reported in older kernels?
    >
    > No, the release dates aren't critical at all.
    >
    > The problem is that if we allow the release to be stalled by bugs it allows
    > one sluggish maintainer to block the entire kernel. At some point in time
    > we do need to just give up and hope that the bug will get fixed in 2.6.x.y
    > or that it'll just magically fix itself later on (this happens, for various
    > reasons).
    >
    > We get in the situation where lots of people are sitting there with arms
    > folded, complaining about lack of a new kernel release while nobody is
    > actually working on the bugs. Nobody knows why this happens.
    >
    > > ESPECIALLY given that patches are said to be available?
    >
    > Things get lost. If there's a patch which needs applying and we've missed
    > it, please please please rediff it, add your Signed-off-by and loudly mail
    > the thing out daily.
    >
    > > IMHO, I agree that new regressions are most important to fix, but I
    > > feel that old regressions are extremely important to fix as well. If
    > > we know of more regressions that CAN be fixed before a kernel release,
    > > why not do it?
    >
    > Fixing many of these things is not trivial, as I'm sure you know from
    > personal experience. The great majority are in drivers and, almost
    > axiomatically, the guy who added the regression cannot reproduce it on his
    > hardware (otherwise he wouldn't have shipped the diff). So the debugging
    > process involves drawn out to-and-fro with the reporter. And it requires
    > quite a bit of work by and help from the original reporter. Depressingly,
    > developers often just don't bother entering into this process in the first
    > place and we shed another batch of mainline testers/users.
    >
    > > Why should there be any rush to release the next mainline version? To
    > > make it in time for Christmas? A better Christmas gift to the world
    > > would be a new release without regressions, be it a month late, who
    > > cares? (I know -- not likely, but at least we should try)
    >
    > We'll regularly hold up a release due to an identified set of bugs. But if
    > we do this we need to be very clear on what those bugs are and we need to
    > be assured that there's a developer actively working on each bug and that
    > the reporter is responding. Without all of that in place, the whole
    > release process would get stalled for arbitrary amounts of time.
    >
    > We need someone who does nothing but track and report upon bugs. It would
    > be a full-time job. We don't have asuch a person. We hope that individual
    > maintainers and subsystem maintainers will track the bugs in their area of
    > responsibility so that such a person is not necessary. But the maintainers
    > don't do this. You see the result.

    Fair enough... (not much else I can say to that -- you're right)

    ... btw, I tested -rc7 and it's smooth as butter...

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

    \
     
     \ /
      Last update: 2005-12-26 03:03    [W:4.695 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site