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

Re: nvidia/fglrx expedited SRUs

2012-09-03 Thread Martin Pitt 
Hello Bryce,

Bryce Harrington [2012-09-03 17:24 -0700]:
 Historically, this is how testing has worked:

Thanks. This gives me sufficient confidence that major packaging
errors and upgrade failures are being spotted. As for broad hardware
compatibility, I guess we have to leave that to NVidia's QA, but it
seems that in the PPA we should get at least a decent selection of
cards already?

   1.  The SRU bug report is a packaging request.  So there really isn't
   a defined test case.  (I guess we could say, Yes, after
   uploading x.y.z to -proposed, x.y.z is available in -proposed but
   that seems silly.)

In this case it should be a regression test -- does the driver
install, upgrade, and build against all supported kernel pacakges that
we have, and does Unity still start?

   2.  The driver changelog tends to be terse 1-2 sentences per fix.  So
   reproducing the original issues can be challenging.

I don't think we need to be too focussed on bug verification, given
that we just have the option between taking the full package and doing
nothing anyway. For this reason we have the -updates package in the
first place, so that we can always ship the latest one without having
to do extensive bug fix verification and hardware covering. But we
should still make sure that it's properly packaged of course. If it
fails to build/link against our current kernel, releasing that would
indeed be pretty shameful.

   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.

It should indeed for ordinary packages. I still think cases where your
computer suddenly doesn't boot at all should be investigated, and the
update delayed; but if the perceived regression is non-fatal, such as
a slight drop in framerate etc., I see no reason to not move it to
-updates, given the purpose of the package.

A.  Immediately after release we have the same major versions in
nvidia-current and nvidia-current-updates.  In this situation, we
allow the SRU team to expedite the upload without needing to wait
for testing in -proposed.
  
  One thing we should keep in mind is that we have had n-c-updates for
  several releases now. So if people installed -updates in e. g.
  oneiric, upgraded to precise, quantal etc., they will have -updates
  from day one. I think for this case, as well as making the process
  have fewer variables, I'd skip this part and only do B.
 
 So that I understand correctly you're suggesting that A be dropped from
 the proposal?

Right.

 If we move people from the -experimental beta driver back to stock on
 upgrade (which I think we might want to do), maybe it would be worth
 considering moving people from -updates back to stock on upgrade as
 well?  That would resolve this use case, and enable us to do the quicker
 release to -updates?

That works for me as well. But I'm not sure whether it's semantically
the right thing: I do agree for the -experimental use case after your
latest reply, but I'm not sure whether the selection of the -updates
driver should be regarded a permanent choice?

But either way, I'm fine with either A and move to standard driver on
dist-upgrade or only B and always keep -updates.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
-- 
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board