Re: nvidia-experimental package with expedited SRU process?

2012-09-17 Thread Colin Watson
On Mon, Sep 10, 2012 at 03:14:49PM -0700, Kees Cook wrote:
> On Fri, Aug 31, 2012 at 10:49:36AM -0700, Bryce Harrington wrote:
> > I think -updates should continue focusing on providing stable,
> > _released_ drivers.  For the beta drivers, we could add a third package,
> > nvidia-experimental, which would be used when needed by specific games.
> > 
> > -experimental would be marketed as "bleeding edge / unstable" but would
> > be provisioned in much the same way as -updates.  We would like to
> > commit to an objective of a 3-day turn around from when the driver
> > becomes available to when it is officially available for users to
> > install.
> > 
> > Would the tech board be open to allowing this specific package to follow
> > an expedited SRU process?
> > 
> > How I'm thinking it'd work in practice is, we would package and upload
> > the driver to -proposed and file a minimal SRU bug report (basically
> > just the Impact section; we're unlikely to know details).  We'd then
> > have the game vendor verify the driver from -proposed works with their
> > game.  The SRU admin would then be able to wave it through at that
> > point.
> 
> +1, I think this sounds good. I think the benefits outweigh the risk.
> 
> The risk I see is in wondering what percentage of the install base will
> end up on it as a result of a game install. If it's large, we run a
> larger risk of breaking someone in the face of a update regression.

I share this concern.  The problem with introducing this kind of
"bleeding-edge, but important things may need it" package is that over
time enough important things need it that you find that it's become
critical-must-not-break without you noticing, and then you end up back
at the start of the cycle.

Bryce, you mention "used when needed by specific games" above.  I'm not
really familiar with the details here and I'd like to ensure I know
exactly what you mean.  Is this something that's per-X-session, so we're
talking about using it when any of a set of specific games are
installed, or per-application, so you could run multiple games in the
same session with different drivers?

Even in the latter case, I can imagine an uncomfortable situation where
we do an -experimental update for Important Game Vendor A and find that
it breaks Important Game Vendor B's best-selling title from last month.
Would we need to arrange testing with all sufficiently important vendors
before releasing updates?  (But then we have the problem where we can't
release a fix for Important Game Vendor A because Important Game Vendor
B hasn't responded, and the incentives here may well be perverse ...)

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board


Re: nvidia/fglrx expedited SRUs

2012-09-17 Thread 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   [cjwat...@ubuntu.com]

-- 
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board