Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762154AbXKMVE0 (ORCPT ); Tue, 13 Nov 2007 16:04:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756781AbXKMVEQ (ORCPT ); Tue, 13 Nov 2007 16:04:16 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:48467 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756457AbXKMVEP (ORCPT ); Tue, 13 Nov 2007 16:04:15 -0500 Date: Tue, 13 Nov 2007 13:04:11 -0800 From: Andrew Morton To: Christian Kujau Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org Subject: Re: [BUG] New Kernel Bugs Message-Id: <20071113130411.26ccae12.akpm@linux-foundation.org> In-Reply-To: References: <20071113034916.2556edd7.akpm@linux-foundation.org> <20071113.035824.40509981.davem@davemloft.net> <20071113041259.79c9a8c5.akpm@linux-foundation.org> <20071113.043207.44732743.davem@davemloft.net> <20071113110259.44c56d42.akpm@linux-foundation.org> X-Mailer: Sylpheed 2.4.1 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2044 Lines: 47 On Tue, 13 Nov 2007 21:00:30 +0100 (CET) Christian Kujau 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 . 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 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 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/