MIR for nvidia-experimental-NNN and nvidia-settings-experimental-NNN

[Bryce Harrington]

The nvidia-graphics-drivers-experimental-304 and nvidia-settings-experimental-304 packages are forks of the nvidia-graphics-drivers package, so as per MIR Note #3 they does not need a full review. But I'll highlight the principle concerns worth consideration:

[Availability]
Uploaded to nvidia-graphics-drivers-experimental-304 and nvidia-settings-experimental-304 in Quantal. Both build for amd64 and i386, the two architectures the driver is relevant for.

[Rationale]
These packages will provide one or more minor versions of upstream nvidia beta drivers, which are not currently provided via any other mechanisms. These are expected to be required by certain 3rd party commercial games at the time of their release. Supporting commercial game vendors is an important goal for Ubuntu and Canonical.

nvidia-settings-* is a tool for configuring the video driver.

For risk reduction reasons, rather than a single nvidia-experimental package which we add new major versions to, we will be packaging each new major series as a separate source package. This way users are exposed to beta drivers at the point they opt-in. See tech board meeting for full discussion on this.

We are asking for MIR for the nvidia-graphics-drivers-experimental-304 and nvidia-settings-experimental-304 packages specifically at this time, but wish to get MIR approval for all subsequent new versions in the nvidia-graphics-drivers-experimental-NNN and nvidia-settings-experimental-NNN series. These will all be essentially the same packaging code, except for different version numbers and blobs.

[Quality Assurance]
These packages are maintained and installed the same way as nvidia alternative drivers, so largely benefits from the QA done on our regular packaging. The mission of the experimental series of packages is to provide less-tested beta drivers, so by definition the level of QA will be lower than with stable nvidia drivers; but the package is opt-in, and a user-visible warning to this effect is included in the driver description.

[Maintenance]
The experimental packages are maintained exclusively in Ubuntu. We will update from upstream as appropriate (such as at request by 3rd party game developers that require newer versions). As this is a closed source binary driver we won't be able to fix most issues, but can pull new beta updates if needed as they're made available, and will of course be tending to any packaging flaws that arise. But our hope is to structure our processes such that this is largely a maintenance-free package that we just update once and a while.

[Security]
 -nvidia has a history of security review including various known issues; this package is no better or worse on this count.

Security Checks, UI standards, Dependencies, Standards Compliance: Same as -nvidia

[Background Information]

1. This package was proposed to the Technical Board for acceptance. It was approved at the Sept 17th meeting.

2. The Ubuntu packaging for this driver is maintained in the experimental branch of the normal nvidia package, at github:
 - https://github.com/tseliot/nvidia-graphics-drivers/tree/experimental-304
 - https://github.com/tseliot/nvidia-settings/tree/experimental-304

3. Once accepted to quantal, will be submitted for SRU to precise (See LP: #1047681)

4. On upgrade to a new Ubuntu release, users who have installed this driver will be automatically returned to the stable driver.

[Michael Terry (mterry)]

Seems fine, as it is a split from existing package, is opt-in, and the plan has tech board approval.

Some hopefully quick questions:
* You say that a user will be reverted to stable drivers upon upgrade. What if that would involve downgrading the major version? (i.e. in a year, some cool new game for 12.04 requires experimental-500 but 12.10 only has 408) And what if they still have that game they installed in 12.04 that needs that newer version?
* Let's say a user installs a new game that requires an experimental driver. But the driver doesn't work for whatever reason. How easy is it to revert for the user? It will involve more than just uninstalling the game. (This is a general driver problem, but I'm curious here, because the user may not fully understand that when they are installing a new game, it will also involve a driver update. i.e. users that just click ok to advance)
* What if game A requires nvidia-experimental-304 but game B requires nvidia-experimental-305? I assume they both install and the alternatives point at 305.
* I notice that the version in quantal now (304.48) is only slightly higher than the non-experimental version (304.43). But it sounds like this setup is largely for newer major number bumps. Is the quantal version basically being used as staging for the SRU?

[Bryce Harrington (bryce)]

A. That's an interesting scenario. Under such a situation the user would be left on a functional Ubuntu install, but the game would not work. Several options come to mind for addressing it, but none seem perfect:
   1. Move them to nvidia-current anyway. There will always be an equal or newer version of the experimental driver in newer releases, so we ignore the breakage and let the user manually re-install experimental after upgrade.
   2. update-manager could warn the user of this case and let them decide whether to proceed with the upgrade. update-manager is what will be switching them to the nvidia-current driver so (handwavy, sorry!) could include logic to compare versions.
   3. update-manager could conditionally keep them on experimental if they have a newer version installed than the new nvidia-current would provide.

In ideal circumstances #3 would give the best user experience since it should keep their game working. But it exposes them to significant risk; who knows what bugs may exist in the new beta driver. #1 avoids this risk but breaks their game. #2 passes the buck by making the user decide.

B. Currently, the games that we're looking at for this will present the user with a dialog that they need to install the driver via Additional Drivers. It won't be pulling the driver in automatically as a dependency. So the user should be aware that they've installed a driver, and should look to addressing that to restore their system. Ideally that just means going to Additional Drivers and switching back. But this may involve running apport-cli if the breakage involves X not starting, or even utilizing a failsafe session in particularly severe cases. Obviously all bad user experiences, but (for better or worse), they're all well trodden paths and we have tools, documentation, and processes to help. Obviously our goal will be to minimize this happening.

C. Regarding two games requiring different beta drivers, historically NVIDIA does not put out two different major beta drivers in parallel. So by the time game B comes out, the prior beta that game A needed will have been released as a stable driver. Game B's beta driver can be expected to provide whatever game A required, so after it's installed both games should work fine. The user will have both installed but only the newer one enabled. On the off chance that game A *doesn't* work with the newer beta driver, the user would then toggle between the two in Additional Drivers. That would be obviously annoying and hopefully never crop up in practice.

D. That's correct, we're using the quantal major version as practice and to stage the SRU. We anticipate 304.48 will go into nvidia-updates eventually, and are mainly taking advantage of it to seed the processes, so that when a real beta driver appears we can hopefully move it through the system faster (our stated goal is 3 days from upstream release for it to appear in the LTS).

[Michael Terry (mterry)]

For (A), I suppose (3) is not so risky, because we could always guarantee to have beta version overlap. For example, we could make sure that 12.10 had experimental-500 and just keep the user on the same version during the upgrade.

For (B), I was thinking more of a situation where the user barely reads the dialog we throw up saying to install more packages (the dialog is basically a big "just make it work" button anyway). In that case, they might not fully expect that installing a new game could affect their whole desktop experience. But we can fallback on our normal X handling for that situation, like you say. Not great, but not many choices, except avoiding experimental drivers.

Well again, not much for MIR team to do here. I'll mark the graphics driver approved. I'll give nvidia-settings a quick look over/rubber stamp tomorrow.

[Bryce Harrington (bryce)]

B. Yeah but for the case in question the game won't have an installer that pulls the driver in with a button click. It will instead be popping up an error dialog and directing the user to install the experimental driver from Additional Drivers.

For cases where we're controlling the installation end to end in Ubuntu such as via USC, some additional thought will need to be done at the application packaging level. But we can cross that bridge if and when we come to it.

[AG Restringere (ag-restringere-deactivatedaccount)]

Just indicating that this bug affects me and is a major issue! I'm dying to keep bleeding edge Nvidia Drivers all the time. When will the new package be available for Precise?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Bryce Harrington (bryce)]

@AG, you want to be following bug #1047681, which is the SRU of this to precise.

[Matthias Klose (doko)]

Override component to restricted
nvidia-graphics-drivers-experimental-304 304.48-0ubuntu1 in quantal: universe/misc -> restricted
nvidia-experimental-304 304.48-0ubuntu1 in quantal amd64: universe/misc/optional -> restricted
nvidia-experimental-304 304.48-0ubuntu1 in quantal i386: universe/misc/optional -> restricted
nvidia-experimental-304-dev 304.48-0ubuntu1 in quantal amd64: universe/misc/optional -> restricted
nvidia-experimental-304-dev 304.48-0ubuntu1 in quantal i386: universe/misc/optional -> restricted
5 publications overridden.

Override component to restricted
nvidia-settings-experimental-304 304.48-0ubuntu1 in quantal: multiverse/x11 -> restricted
nvidia-settings-experimental-304 304.48-0ubuntu1 in quantal amd64: multiverse/x11/optional -> restricted
nvidia-settings-experimental-304 304.48-0ubuntu1 in quantal i386: multiverse/x11/optional -> restricted
3 publications overridden.