Messages in this thread | | | Date | Sun, 25 Dec 2005 20:59:54 -0500 | From | Michael Krufky <> | Subject | Re: 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/
| |