[Ksummit-2007-discuss] Re: Updated topics list

[Andrew Morton]

On Fri, 25 May 2007 14:33:23 -0600 Jonathan Corbet <corbet at lwn.net> wrote:

> Here's the latest version of the topics list (I'll send a diff as
> well).  If there's anything else which needs to be on the list, *now* is
> the time to speak up - especially if it could have a bearing on who
> should be invited to the discussion.
> 

Thanks, Jon.  I come to this late because I set up some procmail rules for
ksummit-07 in January, promptly forgot having done so, then spent a few
months wondering when someone was going to start discussing kernel summit. 
But it's been very peaceful!


My overall take on kernel summit: we spend far too much time talking about
technical stuff.

There is little benefit in doing this: we conduct technical discussions over
email and we do it well, and there are many very good reasons for doing it
that way.  In fact when the KS discussion gets too techy I just start ignoring
it - way too much detail, yet not enough detail, and I know that it will
all come around later on, in proper form, in an appropriate amount of
detail, via email.

Plus the minisummits are better suited for the technical material.



At kernel summit we should concentrate on those matters which *can't* be
effectively conducted via email:

- process

- community

- personalities

- Overall direction-setting.  Those broad-sweep process things.  In
  short, things which affect *how* people do their work, rather than *what*
  work they do.

- relationships with vendors, companies, end-users, testers

- development of consensus on project-wide issues and, critically,
  communication to individual developers the collective will that the
  decisions be followed.

- bitch sessions!

- Heck, let's form a kernel-developer's union and go on strike for a 100% pay
  rise!

- release cycles

- bugs, bug tracking, testing

- code review.  o-my-gawd, can we please spend all two days on this?

- the stable tree, and how to get developers to remember that it exists?

- scalability: how much is too much?

- cleanups: are they worth it?  If so, how do we do them, how do we
  prioritise them, etc?

- how to handle patches which hit on multiple maintainer's code?

- what do to about the sleepy, sluggish or dead maintainer problem?

- can we help those employed-by-OEM driver developers to play better?

- is our present allocation of bodies-to-subsystems appropriate and if
  not, can we fix it?  (aka the give-an-mm-hacker-a-scsi-driver initiative)

- do our employers expect us to spend too much time on features and too
  little on legacy maintenance and if so, should we try to do something
  about it?

- the 80-column rule: is it time to upgrade to 96?

- Can we do anything to enlarge the developer pool?

- Are we merging too much crap and if so, how do we stop?

- Are we going to fast?

- Our main customers are the distros.  Let's hear them tell us how
  we're doing.

- the list goes on.



y'know?  This is our one opportunity per year to get together and to thrash
out those things which we can't (or don't) address over email.

And yet the proposed agenda is at least half-full of boring-as-shit stuff
which we can trivially and do regularly work through via our normal
processes.  We fly halfway around the world to yap on about dentry cache
scalability?  Spare me, we'd get more done by staying home.

This ends up being a lot more interesting as well, because 100% of the
audience have opinions and a stake in the outcome.  Not to mention that
they can all actually understand wtf the other guys are talking about.



So, my bold suggestions for kernel-summit:

a) rigorously avoid any topics which would be better covered (or even
   adequately covered) via email.

b) don't set any topics which are irrelevant to even a small proportion
   of the attendees.

c) When ksummit is in progress, if discussion starts wandering into
   we-can-do-this-via-email territory, chop it off.  Aggressively.


If we cannot find enough such material to usefully occupy the two days then
perhaps KS just isn't paying off, and we should meet every second year or
just stop doing it.



I'll address the proposed agenda in a second email.