Dave Jones (davej(a)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