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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ