Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S265283AbSJRQcw>; Fri, 18 Oct 2002 12:32:52 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S265285AbSJRQcw>; Fri, 18 Oct 2002 12:32:52 -0400
Received: from fmr03.intel.com ([143.183.121.5]:54725 "EHLO
	hermes.sc.intel.com") by vger.kernel.org with ESMTP
	id <S265283AbSJRQcu>; Fri, 18 Oct 2002 12:32:50 -0400
Message-Id: <200210181638.g9IGcdP31359@unix-os.sc.intel.com>
Content-Type: text/plain;
  charset="iso-8859-1"
From: mgross <mgross@unix-os.sc.intel.com>
Reply-To: mgross@unix-os.sc.intel.com
Organization: SSG Intel
To: "Timothy D. Witham" <wookie@osdl.org>,
       "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
Subject: Re: Bug tracking in the run up from 2.5 to 2.6
Date: Fri, 18 Oct 2002 09:41:59 -0400
X-Mailer: KMail [version 1.3.1]
Cc: linux-kernel <linux-kernel@vger.kernel.org>
References: <205680000.1034895125@flay> <1034895725.8879.5.camel@wookie-t23.pdx.osdl.net>
In-Reply-To: <1034895725.8879.5.camel@wookie-t23.pdx.osdl.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1966
Lines: 41

On Thursday 17 October 2002 07:02 pm, Timothy D. Witham wrote:
> On Thu, 2002-10-17 at 15:52, Martin J. Bligh wrote:
> >?We're proposing to create a bug tracking system to help keep track of
> >?2.5 kernel bugs ... in an attempt to help get 2.5 stabilised as quickly
> > as possible.
> >?


Defect tracking works best when used over a significant portion of the 
product life cycle.  In this case this bug data base will be of more use and 
value to 2.6 than anything else.  You'll need to be patient and persistant. I 
think something good has a chance of coming out of this.

Prioritizing bugs and bug fix activities is a political and user / market 
driven activity.  It'll be interesting to watch this shake out.  I wish you 
all the best of luck.

Defect tracking and fixing is a "push" activity.  The owners of 
the bug data base and "the product" along with input from key stake holders, 
dictate the priority and owners of issues (pushes the responsibility onto an 
owner).  The owners then go and make fixes.  This tends to be effective in 
hierarchical organizations.  

The Linux  development model is more of a pull model.  Someone finds a bug 
takes it upon them selves to fix it (pulls the responsibility onto 
themselves), and then attempts to get the fix accepted.  If bugs in some 
areas sit around too long it becomes an opportunity for someone new to step 
up.

Perhaps if you set up the bug queries as a type of advertisement of the "most 
wanted bugs"  that aren't getting  attention could proved a nice place 
for folks to look if they are interested in getting involved / helping out.  
It could also become a type of "wall of shame".  You'll need to be carefull 
to keep things positive.

--mgross
-
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/