Dave Jones (davej@xxxxxxxxxx) 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 _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
