Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Bill Davidsen]

Andrew Morton wrote:

> Michael Krufky <mkrufky@xxxxxxxxx> wrote:
>  
>
> > On 12/23/05, Bill Davidsen <davidsen@xxxxxxx> wrote:
> >    
> >
> > > Andrew Morton wrote:
> > >      
> > >
> > > > Adrian Bunk <bunk@xxxxxxxxx> 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.
>  
Or after some period of time the code causing the regression gets rolled 
back and the patch gets delayed until the regression is fixed or at 
least understood. Other than a fix for an exploitable security issue 
there are few things added in any mailline release which couldn't wail 
until the next mainline or -stable comes out.

Historically patches have been rejected because they were "not the right 
way to fix the problem," even though they did work (some of mine during 
early SMP days, for example). I would hope that introducing a regression 
also qualifies as "not the right way to fix the problem," and 
particularly not the right way to introduce some new feature or 
performance enhancement.

I suspect that the developer of a patch would be more likely to work on 
the regression if it were preventing the fix from going in.

> 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.
>
>  
Good luck. Someone qualified to do that job would also be qualified to 
do more interesting things...

--
bill davidsen <davidsen@xxxxxxx>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

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