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    [from the cache]
©2003-2011 Jasper Spaans