nvidia/fglrx expedited SRUs

[Colin Watson]

On Mon, Sep 03, 2012 at 05:24:40PM -0700, Bryce Harrington wrote:
>   3.  Invariably someone will comment on the SRU bug that they have a
>       regression with the update, that they don't have with stock.  Who
>       knows if they do or not, or even if they're testing the right
>       thing.  But this stops the process cold.

I guess I fall somewhere between Martin and ScottK on this.  Regressions
are supposed to prevent releasing an update, and it would be bad to
release something when we had a warning that it made some systems worse;
but we should also have some kind of get-out in case the regression
can't be substantiated, because sometimes testers are just genuinely
confused.  I'm not fully comforted by the fact that it's opt-in, because
the -updates package is only opt-in *once* and thereafter you get all
updates to it.

Perhaps there is some way we can break this deadlock?  I can think of a
few possibilities for discussion:

 * Make sure that testers know that they need to engage with the process
   and not just fire off an "it's busted" message without follow-up.  We
   could establish something whereby, if somebody tells us about a
   regression with a low level of detail, we'll still do due diligence
   to try to make sure that this isn't something we missed and we'll ask
   them for more detail about it, but we won't consider it a hard
   blocker.

 * Issue more widespread calls for testing that we normally would in the
   event of a reported but unsubstantiated regression.  (Do our QA labs
   get involved in testing updates of non-free drivers?)

 * As you suggest, change ubuntu-release-upgrader (or update-manager for
   upgrades to <= precise) to drop nvidia-current-updates etc. on
   release upgrade in favour of nvidia-current etc.

 * Think of some way in which we can make the package management system
   consider nvidia-current-updates etc. as opt-in on every upgrade.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]