I agree. That's part of it. But part of it is not just the "it's 2 months
until the next release", part of it is also very much a "nothing has
happened in the normal kernel for the last 8 weeks, this is boring, so
I'll do my own exciting stuff".
So one _fundmanetal_ issue is that all the people who aren't directly
involved with a particular regression are simply bored. And bored is not
good. You want people productive - and that meas that you want a
active development kernel that they can work with, since they aren't going
to help with the regressions anyway.
This is why the -stable tree is so useful. It's not only that users want a
stable tree - it allows people who do *not* have regressions on their
plate to not be stuck twiddling their thumbs - they can be on the regular
kernel.
I'm saying that four months wouldn't even have *helped* in the case of
2.6.21.
Do you really think bugs get fixed faster just because there wasn't a
release? Quite the reverse. Bugs get _found_ faster thanks to a release
(simply because you tend to get more information thanks to more users),
giving the stable people more information, causing the bugs to be able to
be found and fixed _more_quickly_ in the stable release than if we had
waited for four months to release 2.6.21.
The two last weeks of 2.6.21-rc were almost entirely "wasted", apart from
getting the e1000 issue at least resolved (which was the reason for that
delay, so I'm not complaining - I'm just saying that not a lot of people
actually were able to _help_ with regressions during that time, and for
some of them, we might well be better off with more information about the
issue).
Did we fix other bugs? Yes. There was one long-time bug (since 2.6.15 or
something) that happened to come in during that time, and we had some
cleanups, we had MIPS bugs, we found some networking issues etc etc. But
the amount of combined effort people put on it was pretty weak.
I disagree. Quite often, having 5 people report the same thing is actually
more useful (because you see a pattern) than having one known regression
that you don't know _why_ that regression happened. And that's the case we
had for most of them.
You have things like the maintainer (see Oliver's reply, for example)
simply unable to reproduce it, and needing more information. It
*does*not*matter* that the original report may be old. If you need more
information, you need more information, and a two-month-old report isn't
any better just because it's two months old.
At some point, you need to say: we're not making progress, need to release
it, that might get us *off* this stuck situation.
That's the part you seem unable to accept. You think that "we have a
listed regression" means that you should be able to fix it. Not so. We
*often* need more information.
So you're going to help exactly how? By stopping to help? Or kvetching
about developers that can't figure out why something regressed.
Sure, that makes tons of sense sense, Adrian.
NOT.
Linus
-
