Adding a hook to ubuntu-drivers GUI for a driver PPA

[Alberto Milone]

On 19-08-15 17:39:59, Jorge O. Castro wrote:
> On Wed, Aug 19, 2015 at 4:46 PM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> > What are you concerned about in particular? The act of uploading
> > obviously doesn't make a difference; is it slow SRU queue processing?
> > Or the 7 days maturing period? The latter is at least an excellent
> > idea as after a new version lands in the distro (or PPA) once, you
> > have a commitment to not break existing users; so they should be
> > exposed to some field testing before releasing.
>
> Ok Adam Conrad explained to me in IRC on a better way to proceed, so
> I'd like to withdraw this request. He recommended doing:
>
> - Use the PPA as a staging area (with perhaps having edgers be the
> truly edgy one)
> - Work on getting ricotz uploading rights for the drivers (if he
> doesn't have that already)
>    - Get mmarley started on the road to becoming an ubuntu developer
> if he so desires.
> - Push the driver updates in as SRUs.
> -  After there are a few upload cycles under the team's belt
> investigate shorter cycles, etc.
>
> Anyone have anything else to add or other advice? Thanks for listening!

A few more points to discuss:

1) Processing packages (of that complexity) in NEW can (and from my
experience will) take a long time, as Timo pointed out. Archive admins
would have quite a few new nvidia packages to review if you do this. Do
we have the resources to do it?

2) Short lived driver releases are short lived in the sense that NVIDIA
stops supporting (i.e. updating) them way before long lived releases
(which are what we currently use in Ubuntu), at which point you will
have to migrate users to another driver (think of security issues,
Xserver ABI support, etc.).

3) New driver releases might also drop support for some graphics cards,
in which case you have to be even more careful when migrating users to
another driver.

4) Kernel updates (not just the backported -lts kernels) will break
compatibility with the binary drivers (again, speaking from experience
here), and that means that somebody with kernel experience will have to
fix the drivers. Currently I take care of this, and the number of
drivers to fix is somehow manageable (I am not full time on this) but,
if you go ahead and making all those drivers available in our stable
repositories, then it won't be the case any more. Is the kernel team (or
anybody else with proved kernel experience) committed to fixing the
drivers when kernel updates break them?

As the current maintainer of the nvidia and of the fglrx packages I have
to NACK this proposal, unless you can prove that we have all the
resources to make this possible in a way that is both robust and
reasonable maintenance-wise.

P.S. Keeping the current semi-official PPA seems much more reasonable to
me.

Regards,

--
Alberto Milone
Software Engineer
Hardware Enablement Team
Professional and Engineering Services