On Tue, 13 Nov 2007 21:00:30 +0100 (CET) Christian Kujau <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Nov 2007, Andrew Morton wrote: > > I think that we're fairly good about working the regressions in > > Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to let > > the unsolved ones slide, and we don't pay as much attention to the > > regressions which 2.6.x testers report. > > Can't we wait until all regressions[0] are fixed before releasing a new > 2.6.x? I'd consider regressions a *literal* show stopper, and with this > policy they just have be fixed, nothing would "slide"... > Problem is that everyone would then sit around pumping shiny new features into their trees waiting until someone else fixes the regressions. There are a number of process things we _could_ do. Like - have bugfix-only kernel releases - Just refuse to merge any non-bugfix patches for a subsystem when it is determined that the subsystem has "too many" regressions. - Create an "if you added a regression, you should fix some other bug too" rule. - probably other stuff. But we can't/shouldn't do any of that until it is generally agreed that we have a problem and that the problem is of sufficient magnitude that process changes are needed to address it. We aren't at that stage yet. Here's an important point: developers have a fixed amount of development time. They spend some of that time fixing bugs and the rest of that time on <otherstuff>. And while one could cook up all sorts of wonderful process changes, they all would be aimed at a single thing: shifting some of the developers' time away from <otherstuff> and onto bugfixing. At this stage the only tool which is being deployed to attempt to bring about that reprioritisation is suasion. aka "lkml flamewar". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
