public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: ksummit-2008-discuss@lists.linux-foundation.org
Cc: Arjan van de Ven <arjan@linux.intel.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss	list
Date: Fri, 27 Jun 2008 10:35:22 -0700	[thread overview]
Message-ID: <200806271035.22856.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <4864FEFB.2050405@linux.intel.com>

On Friday, June 27, 2008 7:53 am Arjan van de Ven wrote:
> James Bottomley wrote:
> > Hi All,
> >
> > This is the synopsis of the currently suggested topics so far.  That's
> > not to say this is the list we will be doing, just to say that if
> > there's something you think we should be discussing and it's not on the
> > list, now would be a good time to add it (don't trust the programme
> > committee magically to add it at the last minute ...)
> >
> > James
>
> I'd like to propose a topic about kernel quality; there's been a lot of
> lkml traffic about it (in ups and downs). As part of this topic I could
> present trends, data and conclusions from the kerneloops.org project. I'm
> sure Andrew has a set of data and views from his part of the world, and the
> regressions topic could fall under this too. If we, unlike last year, ask
> various subsystem maintainers to prepare data or at least something more
> solid than "eh I think we're fine" ahead of the conference, we could have a
> more thought out set of inputs from that direction as well.

I think this could be an interesting topic, as long as we have data like what 
you collect at kerneloops.org.  Unfortunately, data for other stuff is harder 
to come by.

Another question this raises is how we define "quality".  Is it simply having 
a low bug count?  Or just having few bugs that affect large numbers of 
people?  Given that we'll always have bugs though, we could also measure 
quality in terms of how effectively we handle bugs, e.g. how quickly fixes 
are proposed and integrated, how well we work with distros to incorporate 
fixes for their high priority issues, etc.

If we measure quality using bug metrics, things are pretty hard.  We have 
kerneloops.org which tracks one class if issues, but there are so few bugs 
filed at kernel.org, relative to other projects that use bug tracking 
heavily, that for PCI at least I could only paint an anecdotal picture of 
things (though we do have one fairly clear area of weakness that I've seen 
based on my triaging).  Contrast this to the Intel graphics projects at 
freedesktop.org where we have a fairly large bug history and can say pretty 
convincingly that things are improving a lot, and fairly rapidly.

I guess I'm saying this *could* be an interesting topic, but it could also be 
the same discussion we've had for years, which never even reaches a 
conclusion about whether we're improving or not.

Jesse

  parent reply	other threads:[~2008-06-27 17:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-27 14:41 Current List of Kernel Summit suggested topics from the discuss list James Bottomley
2008-06-27 14:53 ` [Ksummit-2008-discuss] " Arjan van de Ven
2008-06-27 15:09   ` James Bottomley
2008-06-27 15:19     ` Rafael J. Wysocki
2008-06-27 17:35   ` Jesse Barnes [this message]
2008-06-27 18:11     ` H. Peter Anvin
2008-06-27 18:23       ` Jesse Barnes
2008-06-27 15:19 ` Christoph Hellwig
2008-06-27 17:18 ` Jens Axboe
2008-07-03  9:29 ` Arnd Bergmann
2008-07-03 18:27 ` [Ksummit-2008-discuss] " Greg KH
2008-07-03 23:59   ` Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200806271035.22856.jbarnes@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=arjan@linux.intel.com \
    --cc=ksummit-2008-discuss@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox