Michael Krufky <[email protected]> wrote:
On 12/23/05, Bill Davidsen <[email protected]> wrote:
Andrew Morton wrote:
Adrian Bunk <[email protected]> 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.
