Current List of Kernel Summit suggested topics from the discuss list

Current List of Kernel Summit suggested topics from the discuss list

[James Bottomley]

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

---

Meta Topics:

     1. Do KS as an unconference - Matthew Wilcox
     2. Do a Mini Hackfest for 50% of the time - Greg KH
     3. Expand to three days and do Tech/Process/Tech on each day - Dave
        Miller

Agenda Topics:

     1. Asynchronous Operations - Ulrich Drepper
              * How do we make programs more parallel (driven by
                multicore)
              * Can we use tasklets for this
     2. Fixing the Kernel Janitor's Project - James Bottomley
              * KJ Isn't a good intro to kernel hacking, need better
                ones like bug finding and fixing.
              * Need to find more ways for non coders to make useful
                contributions
              * Need to think more about what 'useful contributions' are
              * What about the kernel tester's project [Adrian Bunk]
     3. Moving firmware Blobs out of the Kernel - David Woodhouse
              * remove all firmware and repackage in ways that would
                either be pulled in at runtime or could be linked into
                the kernel (distro choice)
              * Need to be careful about licensing compatibility
              * Where should we actually keep the extracted firmware
     4. Barriers - Neil Brown
              * Need to define what semantics filesystems actually want
              * Need to relate this to what devices and subsystems can
                actually provide.
     5. Tracking Regressions - Rafael Wysocki
              * Describe experiences with the current running of the
                regression lists
              * How could we make the current list and practice more
                useful
     6. Discuss new Suspend/Resume Framework - Rafael Wysocki
              * Discuss semantics of what drivers should be expecting
                and what best practices are.
              * Need better documentation on this
              * can we make subsystem libraries of helpers for their
                driver suspend/resume to ease the pain?
     7. Hack/Fix session for Laptop Suspend and NOHZ/idle - Thomas
        Gleixner
              * Perhaps this should be done at Plumbers instead
     8. Content Accessed Filesystems - Lars Noschinski
              * Filesystem that would store the same block only once
              * Would be useful for git [Pavel Machek]
     9. When should Drivers be Merged - James Bottomley
              * Options seem to be ASAP, Wait for a bit for it to
                mature, when the vendor has fixed the obvious bugs
              * Have a fast submission track for drivers for which the
                hardware documentation is available [Tony Luck]
              * Run driver submissions early through staging trees while
                they get fixed
                      * How should these be run? Centrally or in
                        subsystem trees
                      * Should staging trees be part of linux-next

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

[Arjan van de Ven]

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.

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

[James Bottomley]

On Fri, 2008-06-27 at 07:53 -0700, 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.

Really, then you want this topic:


>      5. Tracking Regressions - Rafael Wysocki
>               * Describe experiences with the current running of the
>                 regression lists
>               * How could we make the current list and practice more
>                 useful

broadened to include all quality issues?

James

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

[Rafael J. Wysocki]

On Friday, 27 of June 2008, James Bottomley wrote:
> On Fri, 2008-06-27 at 07:53 -0700, 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.
> 
> Really, then you want this topic:
> 
> 
> >      5. Tracking Regressions - Rafael Wysocki
> >               * Describe experiences with the current running of the
> >                 regression lists
> >               * How could we make the current list and practice more
> >                 useful
> 
> broadened to include all quality issues?

That would be fine by me.

Thanks,
Rafael

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

[Jesse Barnes]

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

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

[H. Peter Anvin]

Jesse Barnes wrote:
> If we measure quality using bug metrics, things are pretty hard.

One problem with any metric is that the metric becomes a driving factor 
in itself.  Consider the whole whitespace issue, for example.

As far as the whitespace issue is concerned, we may want to consider 
just setting a flag day -- probably immediately before an -rc1 release 
-- and just run "cleanfile" on the whole tree.  In-flux patches are 
still appliable with "patch -l", and by now we should have enough tools 
to avoid adding new whitespace problems, so we can just kill this issue 
once and for all.

	-hpa

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

[Jesse Barnes]

On Friday, June 27, 2008 11:11 am H. Peter Anvin wrote:
> Jesse Barnes wrote:
> > If we measure quality using bug metrics, things are pretty hard.
>
> One problem with any metric is that the metric becomes a driving factor
> in itself.  Consider the whole whitespace issue, for example.

Sure, but I don't think that's a reason to avoid metrics altogether.  We've 
already seen that purely qualitative discussions don't really get us 
anywhere.  For any discussion about kernel quality I think we have to:
  a) define our goals (no oopses?  fast bug fix turnaround?  whatever)
  b) define a way to measure progress against those goals
  c) periodically re-evaluate both

I think all of these are fairly difficult tasks, and any goal or metric we 
create will have problems, but does that mean we should just ignore quality?  
Or limit ourselves to our current situation where everyone has a different 
idea of what it means and whether we're achieving it?

Jesse

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

[Christoph Hellwig]

On Fri, Jun 27, 2008 at 09:41:49AM -0500, James Bottomley wrote:
>      8. Content Accessed Filesystems - Lars Noschinski
>               * Filesystem that would store the same block only once
>               * Would be useful for git [Pavel Machek]

This is an intersting research topic, but nothing that needs to be
discussed at KS.  It's a pure filesystem implementation issue, and
not a kernel-wide dsicussion item.

Re: Current List of Kernel Summit suggested topics from the discuss list

[Jens Axboe]

On Fri, Jun 27 2008, James Bottomley wrote:
>      4. Barriers - Neil Brown
>               * Need to define what semantics filesystems actually want
>               * Need to relate this to what devices and subsystems can
>                 actually provide.

Again? Barriers must be the most persistent topic at the kernel summit,
yet nothing has happened since my initial implementation back in 2001 or
so! :-)

This being a fairly wide and technical topic, I think it's actually
better suited for mailing list discussion for starters.

-- 
Jens Axboe

Re: Current List of Kernel Summit suggested topics from the discuss list

[Arnd Bergmann]

On Friday 27 June 2008, James Bottomley wrote:

> Agenda Topics:
> 
>      1. Asynchronous Operations - Ulrich Drepper
>               * How do we make programs more parallel (driven by
>                 multicore)
>               * Can we use tasklets for this

I suppose you mean "threadlets" or "syslets" here, not "tasklets",
which are a kernel internal concept, right?

	Arnd <><

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

[Greg KH]

On Fri, Jun 27, 2008 at 09:41:49AM -0500, 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 ...)

Another proposal:

	Working well with other subsystems - Jean Delvare

	There are a number of times where different subsystems in the
	kernel need to interact with each other in ways that are not
	always easy or obvious.  This talk will be about some examples
	of how this has been done well, as well as work to figure out
	how to handle this better in the future.

thanks,

greg k-h

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Thu, 3 Jul 2008 11:27:07 -0700 Greg KH <greg@kroah.com> wrote:
>
> Another proposal:
> 
> 	Working well with other subsystems - Jean Delvare
> 
> 	There are a number of times where different subsystems in the
> 	kernel need to interact with each other in ways that are not
> 	always easy or obvious.  This talk will be about some examples
> 	of how this has been done well, as well as work to figure out
> 	how to handle this better in the future.

Hear! Hear! :-)

This could be expanded into a general discussion of how to handle API
change in our distributed environment.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]