Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760065AbXFQMHL (ORCPT ); Sun, 17 Jun 2007 08:07:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758764AbXFQMG6 (ORCPT ); Sun, 17 Jun 2007 08:06:58 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:33275 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758525AbXFQMG6 (ORCPT ); Sun, 17 Jun 2007 08:06:58 -0400 From: "Rafael J. Wysocki" To: Oleg Verych Subject: Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21)) Date: Sun, 17 Jun 2007 14:13:39 +0200 User-Agent: KMail/1.9.5 Cc: Michal Piotrowski , Andrew Morton , Adrian Bunk , Stefan Richter , Linus Torvalds , Andi Kleen , Diego Calleja , Chuck Ebbert , Linux Kernel Mailing List References: <6bffcb0e0706170322j3c51868fn6189bfd7d3bcac1@mail.gmail.com> <20070617114709.GD16016@flower.upol.cz> In-Reply-To: <20070617114709.GD16016@flower.upol.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706171413.40890.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1716 Lines: 45 On Sunday, 17 June 2007 13:47, Oleg Verych wrote: > On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote: > > On 17/06/07, Andrew Morton wrote: > > >On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski > > > wrote: > > > > > >> +If the patch introduces a new regression and this regression was not > > >fixed > > >> +in seven days, then the patch will be reverted. > > > > > >Those regressions where we know which patch caused them are the easy ones. > > >Often we don't know which patch (or even which subsystem merge) is at > > >fault. > > > > > >I think. How many of the present 2.6.22-rc regressions which you're > > >presently tracking have such a well-identified cause? > > > > > > > Here lays the problem. > > > > git-bisect is a killer app, people should start using it. > > It's OK _only_ in case of unknown, hard to find *hardware* bugs. > > If you think it's "a good thing" for bad, untested by developer > code, then something is completely wrong. Oh, I've just fixed two purely software bugs pointed out by binary searching in the code that I'm sure has been tested, not only by its developers, but the bugs only showed up in my configuration (on one out of four test boxes). There are so many different kernel configurations possible that there's no way a developer can test them all. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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/