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
