F7 redux, and the road to F8.

[Bill Nottingham]

Dave Jones (davej at redhat.com) said: 
> 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.

How much of this is "devices changed names" issues, versus "new
code doesn't quite work"?

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

Make it get upstream. No, I don't know how 'make it' works.

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

Upstream doesn't seem to be moving with any real quickness, which
is somewhat sad.

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

As it's decoupled, exactly how much pain are we running into with
various fixes (PATA/SATA, suspend, etc., etc.) not being consistent?

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

I'd say somewhere between 1-2 weeks, definitely. Enough time to do
real regression testing on a variety of hardware.

Bill