F7 redux, and the road to F8.

[Jeremy Katz]

On Thu, 2007-06-07 at 15:17 -0400, Dave Jones wrote:
> 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?

Not sure of a good answer here.  Hopefully with mac80211 upstream
in .22, we'll start to see some of the drivers filter that way for .23
and that will help a bit.  iwlwifi being in that category is going to
probably take some heavy lifting and someone diving in to just patchbomb
them :-/

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

I think that more of the problems here really are with the way quirks
work changing and not being fully understood.  eg, the quirks are only
used when you suspend via hal but not if you just invoke pm-suspend(!).
At least, I didn't realize that until pretty close to release time and
thus was very confused when suspend via the menu didn't work but running
pm-suspend did :-)

More concerted effort on testing this out is probably the only thing
that can really help.  Maybe try to organize a bug day with Will and
couple it with a live image being available for people to test with?

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

And there's also the kvm-xen stuff that could serve as a replacement for
the dom0 bits :-)  Even if not, it's probably worth getting the domU
bits into the regular kernel because then we can simplify some of the
installer stuff quite a bit.

More generally, I think we want to look at enabling pvops and seeing
what kind of hit it has.  If it's not too bad, it'd be good to have it
on since more and more is going to be using it...  there's already the
VMWare implementation and the KVM pvops discussion is taking off again.

> Last minute breakage.
> ~~~~~~~~~~~~~~~~~~~~~
> 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.

Sounds like a good plan to me.

Jeremy