[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200806271035.22856.jbarnes@virtuousgeek.org>
Date: Fri, 27 Jun 2008 10:35:22 -0700
From: Jesse Barnes <jbarnes@...tuousgeek.org>
To: ksummit-2008-discuss@...ts.linux-foundation.org
Cc: Arjan van de Ven <arjan@...ux.intel.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists