FFe for EnvyNG

Can you exclude this branch (since I've moved its content to envyng-core), please?
https://code.launchpad.net/~albertomilone/envy/envyng

Thanks

Sure. ACK #1.

Sorry Alberto, can you please update the branch status in LP then? https://code.launchpad.net/~albertomilone/envy/envyng/+edit

We're supposed to have a reviewed and tested package before we do the FFe.
I'd suggest whoever is packaging this upload to REVU so it's clear what's
being discussed.

Is the old Envy in the archive?

No, the old Envy never was in the archive, but one of the most used 3rd party apps around: http://www.albertomilone.com/nvidia_scripts1.html

Alberto put a lot of effort into getting https://wiki.ubuntu.com/EnvyNG into shape and comply with ideas Ben, Michael and Bryce had about the topic.

Scott: iirc it's the other way round, first FFe then reviews. Or do I remember s.th. incorrectly?

I have changed the status of my branches.

A brief explanation:
This branch contains the main program, the textual interface and the translations:
https://code.launchpad.net/~albertomilone/envy/envyng-core

This branch contains only the QT4 interface:
https://code.launchpad.net/~albertomilone/envy/envyng-qt

This branch contains only the GTK interface:
https://code.launchpad.net/~albertomilone/envy/envyng-gtk

The code was reviewed and we worked together so that EnvyNG could not cause any problem to Ubuntu. Furthermore EnvyNG relies upon my PPA (reviewed by Ben Collins), thanks to which I can update the versions of the drivers without having to update EnvyNG. The drivers in the repo use DKMS and don't break anything since they coexist with Ubuntu's l-r-m without problems.

If you have further questions I'll be glad to answer.

Alberto

I don't think the package needs to be perfect, but there ought to at least
be a draft.

What significant advantage is there to stuffing this in at the last minute
over an early backport fron Intrepid?

>The code was reviewed and we worked together so that EnvyNG could not
>cause any problem to Ubuntu. Furthermore EnvyNG relies upon my PPA
>(reviewed by Ben Collins), thanks to which I can update the versions of
>the drivers without having to update EnvyNG. The drivers in the repo use
>DKMS and don't break anything since they coexist with Ubuntu's l-r-m
>without problems.
>
By policy we don't take software updates from 3rd party repositories. The
fact that it's hosted on the same service as Ubuntu doesn't make it any
less 3rd party.

N'ACK from me. This doesn't mean it's not a great package, but this is a
pretty fundamental policy problem.

Scott:
Just to make things clear, we've been working on this since December 2007. It's not something we decided yesterday.

If by "3rd party repositories" you refer to my PPA, I really fail to see your point.

The packaging is already done, it's in bzr too.

The old envy used to build kernel module packages from the binary blobs on the net. What EnvyNG does is rely on packages that are distributed over PPA. This makes life easier for people who rely on the latest and greatest drivers to make use of their cards.

There's no fundamental policy problem as far as I can see. What about googleearth-package or flashplugin-nonfree? The mechanism that Alberto uses is much more foolproof than what those packages do (and have been doing for years in the case of flash).

In the case of other package like the nonfree Flash, we upload a set
package based on md5sum. When Flash gets updated, we update the package
via -proposed and then -updates. IIRC the Google packages are distributed
by Canonical in Partner and are not part of Ubuntu.

A PPA is not an Ubuntu repository. I am aware of no case of Ubuntu
allowing software distributed by an externally controlled entity to be
automatically changed.

Thinking about this some more, I think Canonical sponsoring this through
Partner would probably be the best solution.

I tend to agree with Scott on this. This might well be one of the most used universe packages and stuffing this in at the last moment without any evidence of any testing doesn't look very wise.

1) Directory: pool/multiverse/g/googleearth-package
2) I don't see how it could go into 'partner' - 'partner' is for Business partners of Canonical.
3) Alberto agreed to send out a notice to solicit testing of packages in PPA.

Lots of work has been put into making EnvyNG a maintainable solution which does not clash wrt updates, etc: this is effectively the integration of one of the most-widely used 3rd party apps.

Ok, I've taken a closer look now.

First off, there is no policy problem: The package itself doesn't do anything that's not coming from an official mirror in the *packaging*. Programs that the package ships do so, but that's perfectly allowed (a webbrowser with javascript also downloads code from somewhere and executes it for example). Likewise a program may also overwrite config files and do other potentially harmful stuff (e.g. dist-upgrader does exactly this, or any other gui to create/modify config files).
Likewise, imho the package can live in universe, as the contents appear to be fully licensed under gpl. (I can download non-free stuff with wget, but still it's in main).

From a packaging perspective, it looks quite good, I've only seen a minor nitpick that I'd put it all in one source package, but even that's not really a problem. But I didn't look too close though (and also didn't do a test-build). Nonetheless, I believe that the packaging is pretty much in a releasable state, or would only have to go through minor fixes.

From looking at the program, however there still might be a blocking issue: I've seen md5sums in there, which generally is a good thing, but might be a problem here: Are these used to verify the driver versions? If so, how would envy in hardy be able to download newer driver versions, once these are released? Alberto, maybe you can shed some light if I saw this correctly?

Points for me to consider
1) it would be used by a great number of people
2) Cesare's words hold some wisdom: stuffing this in at the last moment might not be the best option because of 1).

This currently makes me a little bit unsure and I have a slight tendency to prefer the route via -backports (with a real high priority once intrepid opens).

P.S.: I'm quite aware that envy is actually fixing a bug elsewhere, and that bug is the beast l-r-m, which cannot get backported easily for new drivers. However I don't think it will get fixed there anywhere soon.

Stefan:
The md5sums are still there but are no longer used (the md5 were necessary when used to EnvyNG built the packages locally). I can comment out that part of the code if you deem it necessary.

So, this has been in the making from December.

Did i miss the correspondence over this package being up for review back in December or so? I'm aware that i'm not subscribed to the REVU list, but I would have expected to see something in #ubuntu-motu, as it's a commonly used package.

If so, I apologize.

"Ben Collins, Bryce Harrington, Daniel Holbach and Michael Vogt reviewed EnvyNG."

The packaging is really simple, but that's not what took so long to be reviewed - it was the integration of the code.

I still don't see a compelling rationale for a new package now vice using the regular review process for Intrepid and then backporting.

For background, some of the discussion/plans were captured at https://wiki.ubuntu.com/EnvyNG. Not sure if that's still 100% up to date though.

I've reviewed the Xorg portions of the package in depth, and the remaining portion of the code in brief. All issues I raised were addressed and I have no reservations about seeing this included in universe. I've found Alberto to be responsive at getting fixes in swiftly and welcoming my constructive criticism.

I plan to recommend use of Envy as a solution for users encountering bugs in Hardy's fglrx/nvidia that are fixed in newer fglrx/nvidia, since we can't reasonably backport l-r-m itself, and Envy at least allows users to upgrade their drivers in a way that won't cause breakage when upgrading to a future Ubuntu, or to newer versions of l-r-m.

I have no position on the review process except to apologize for not raising attention to it earlier (we didn't make any secret of the work, but maybe didn't work hard enough to notify everyone early enough). It would be nice to see this available by the Hardy release, but if people feel that the package needs more time for review, I would not wish to see the process rushed.

If the decision is to review it some more, it'd be good to know what should be reviewed or what is unclear.

Based on the MOTU sponsoring process, nothing has been submitted to be
reviewed.

Scott: Ben Collins, Michael Vogt, Bryce Harrington and I reviewed the package not only for the packaging but the code base. I subscribed them all to the bug.

I just looked on REVU and there's still no package.

The source is in bzr and was worked on for weeks collaboratively. If you want the email threads of ~70 emails about the review of it, I can forward it to you.

On Wednesday 09 April 2008 10:06, Daniel Holbach wrote:
> The source is in bzr ...

Chosing to use tools that aren't the ones we've standarized on will limit the
number of people who look at it.

I'm against adding this to Universe.

1. It's only purpose is to support proprietary software.

2. Based on the blog posts I read on planet, there is not a history of long
term stability. I think it's reasonable to expect SRUs being needed and an
additional maintenance burden on an already stretched MOTU team.

3. It's late. I have yet to hear a compelling reason why this package should
get special treatment and for me #1 and #2 are reasons that argue against it.

If Canonical wants it (that's my impression), my suggestion is to either:

1. Get a Main FFe for it and upload it there.

2. Treat it as outside the distro and put it in partner.

 - Regarding bzr: you can't really say that people have not looked at it yet. I mentioned a couple of times who helped with the integration of it. Also regarding "standarized on": lots of pieces that are developed for the distro are in bzr - how is it relevant to the FFe discussion?
 - Regarding the "Canonical" bit: Envy always was a community project. It has a big user base but had problems regarding its integration into Ubuntu. Michael established the contact, Bryce helped with X integration, Michael with various bits along the way, Ben helped with Kernel bits and I helped with packaging and so on. This is not a Canonical project and can't go into 'partner'. There's no "Canonical" business interest there, the people I mentioned above had an interest in making one of the most wide-spread 3rd party packages more compliant with our distro.
 - Please replace "Proprietary software" with "drivers people need to make their hardware work".
 - Alberto has proven that he's very quick to investigate issues, I don't suppose that he will cause much work for the MOTU team.
 - Other packages got the special treatment of inclusion before, I personally find Bryce justification completely sufficient.

I won't object if someone else from motu-release wants to ack this.

Although this hasn't gone through the standard 'revu' process, it has had eyes on it from several folks that are core-dev which should be equivalent if not better. I've corresponded with Alberto over a few of these things that went into this, and he is very committed to providing an interim solution to the problem of "newer drivers".

I've been thinking about this yesterday when I was under the shower. My conclusion is, that it's very late in the cycle for a new package, which worries me quite a bit. However it would imho still be very nice to have. Now, if someone with upload rights would promise commitment to EnvyNG (i.e. promise to personally look out for bugs, work with Alberto to get SRUs done, if necessary), then I'm happy to get it in at this late moment. Oh, and I guess bribing archive-admins to process this in source-new would also fall under this.

Side story, why I want it in:
Well, I'm a more or less happy user of the nvidia blob. A little bit more than a year ago, my old nvidia card broke so I bought an 8500. Unfortunately it first wasn't supported by nvidia themselves (the nv driver worked, but it was really slow, making e.g. font rendering when scrolling in a terminal a pain). Once nvidia finally updated the driver, it took a very long while to get it in via l-r-m. And this was only the development distribution, not a released one. Imho nvidia will sooner or later break their own compatibility again with newer cards, and I think that envyng could be a very good solution in that regard to at least provide one way for people with newer cards to make them work with hardy in a straightforward way w.o. breaking their system (i.e. by running the nvidia installer).

I'm willing to give this an ack, due to what it offers users for newer hardware/drivers in the future, especially for an LTS. A couple of things I noticed with the envyng-core branch though.

In envyng.list, as far as I understand it, PPAs only put packages in main, there is no restricted.
There is an archive.ubuntu.com entry, but hardy-updates, and hardy-security are not listed, it may be worth listing these in the file.

Other than that, an ack from me.

Alberto: can you take a look at envyng.list and see what needs to be fixed?

Bryce and Michael: would you take over the task of helping Alberto with uploads and SRUs (if necessary) together with me?

Luke: thank you very much. I have corrected envyng.list as you suggested.

Daniel, Bryce, Michael: the correction is in revision 39 of my bzr branch.

How many uploads of EnvyNG will you want to make before release?

By the planet spam (which I still think is ridiculous - a lot of people really don't care each time envy gets updated, especially when they don't use it - but i digress), it appears that this is a package which a high number of uploads - 5 between march 2 and april 2 - and those are just the ones blogged about - i'm unsure if there are releases in the middle.

It seems fairly likely that this will always be out of date - even worse than wine tends to be.

Sarah: Envyng won't need to be updated unless there are bugs (reported by users) like any other package. When a new driver is released, I will only have to update my PPA (without touching EnvyNG).

If SRUs are required, I will be happy to assist with them (being a member of the sru-verficiation team) and help sponsoring the fixes.

I think its better to have the package in the archive and to be able to issue regular SRUs that people get through the regular channels than if we do not provide a repository and have little chance to issues updates to every envy user.

ok, since I haven't seen veto's here, my ACK together with Luke's make two, setting to confirmed.

Oh, please make sure to talk to archive-admins when uploading, thanks.

Thanks, uploaded.

I'll take care of the bribing, thanks guys. ;-)

please close freeze exceptions in uploads... otherwise the karma is all mine :P. Closing.

stefan, was my, norsetto's, and scottk's n'acks not enough? Do we need to actually use the word "veto" now, rather than saying "we don't want this to go in"?

Security concerns: while people using Envy are already directly installing software from a non-official repository, if they switch to EnvyNG, they are no less safe. However, since EnvyNG is installable from the repo directly now, it is likely there will be more people installing it, which means more people will be potentially vulnerable to a breach of the PPA driver updates. It would be better if updates were being reviewed by motu or core-dev for issues. Doing full testing is out of scope, this the whole purpose of envy is to provide bleeding-edge drivers.

License concerns: are the drivers in the PPA redistributable? I assume so, since they're in a PPA. If so, why can't they be put into multiverse? They don't change so often that it would be a burden to do SRUs for them, especially if a standing SRU exception was made for Envy drivers.

I have opened bug 220385.