linux-kernel - Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/