F7 redux, and the road to F8.

[Dave Jones]

I've been doing some thinking about "what went right/wrong" about F7
from the kernel standpoint, and how we can improve for F8.
Wrt 'what went right', I don't have much to say.
Not because nothing went right, but mostly because there was nothing
really positive that stood out over earlier releases.
The new firewire stuff was probably the only thing that went really
well.  Kristian jumped on bugs quickly when they were found, we
got updated kernels out quickly, and best of all, it's now upstream.


The 'what went wrong' category gives me a bunch of ideas of areas
where we can improve however.

libata.
~~~~~~~
Looking at the incoming bugs, this seems to be the biggest area
where we have problems.  No surprise really given the switchover
to new pata drivers.  Though there are quite a few SATA bugs too.
I'm not sure what more we can do here other than keep pointing
Jeff & Alan at them, and hoping for the best.
We knew this was going to be bumpy first time around, so hopefully
for F8 we'll have most of the kinks worked out here, and won't
have introduced (m)any new problems.

Wireless.
~~~~~~~~~
Well, we got dscape and a bunch of new drivers in.
They don't seem to work too well though.  For this to improve,
we really need more bodies.  This was pretty much all linville.
How can we get more interaction from the various upstreams?
ipw3945 seemed to be busted for weeks on end, with very little
motion from Intel. How can we get them more involved?

Nouveau.
~~~~~~~~
This was pretty much a 'dump in the tree and forget' activity.
It really needs someone with the time to babysit it and make sure
it actually progresses.  Ideally, we'd have someone involved
in improving the driver driving this along.  Again, we lack bodies.
I doubt this is going to change much in the F8 timeframe.

Suspend/Resume.
~~~~~~~~~~~~~~~
We need a more focused testing effort here.
(And an even more 'fixing' effort when problems are found).
I fixed up 2-3 laptops in the last few weeks before release,
but pretty much every review I've read of F7 so far has dinged
us for this not working out the box. On common laptops like thinkpads
too.  In part, this was us moving to new suspend infrastructure,
so I'm hoping a lot of the 'black screen' bugs will just go away
in a future hal-data/pm-utils update.  But we can definitly do
better here.  Work is ongoing to get better debugging tools
for resume failures too, more about that as it happens.

Xen.
~~~~
This might get interesting to watch for F8 if XenU gets upstream
(Which akpm seems to suggest it might).  Given we've decoupled
kernel/kernel-xen, we might want to just disable the upstream variant
until F9, and wait until we have both the dom0 and the domU stuff
coming from the same pieces.  Will need more discussion with
the virtualisation team when that lands in Linus' tree.

Last minute breakage.
~~~~~~~~~~~~~~~~~~~~~
The number one lesson I think to be learned was that just because
upstream -stable is called -stable, it isn't necessarily so.
The last minute rebase to 2.6.21.2 brought in the regression that
broke a lot of Dell laptops, and wasn't understood & fixed in time
for release.

For F8 onwards, I propose that we don't jump to the latest upstream
stable release as a last minute thing.  Maybe hold off for the last
week (maybe 2 weeks?) allowing only *really critical* changes.
Where really critical ==

- Fixes a "machine won't boot" bug.
- Fixes a "ethernet doesn't work" bug (thus preventing updates being downloaded)
- Fixes a data corruption bug.
- Fixes a _critical_ security bug.
  (Lower impact things like information leakage can wait until update 1 on
   the day of release).
- Anything else?

The thing is, we nearly always do an update just after the release
anyway, so not-so-critical stuff that doesn't fall into the above
category can go out as an update.

It'll be a bit more work to do more backporting, but I think the
overall risk will be lower if we cherry pick.

On the subject of backporting, due to us only having 5 months
for F8, and a lot of that time being 'conference season', I expect
upstream to slow down a little, so we're probably looking at
2.6.23 for F8.  I'm guessing .24 will begin way too late in our cycle,
so we'll have quite a bit of backporting to be doing for the final
month or so before release.


comments?

	Dave

-- 
http://www.codemonkey.org.uk