Serious concerns about ARB policy (was Re: Basenji)

[Elliot Murphy]

Thanks for reviewing this app. However, I have some concerns with the criteria we are supposed to be using. As I have thought about things for a few hours I realize these are serious enough that I think we need to postpone doing reviews until we can have a reset of the review criteria, hopefully at UDS. I've realized I don't want to endorse things as they stand now, but I also remember that I signed up to constructively help evolve a process which I think we need in Ubuntu. My hope is that we can quickly fix the biggest problems with the review criteria so that we can produce some useful results that allow people to ship apps on top of Maverick, as planned.

Allison, this is not a complaint about your review, which was totally following the current criteria. It is a complaint that I think the current criteria are producing results which are counter to the essence and spirit of the ARB that I signed up for.

On Oct 1, 2010, at 5:37 PM, Allison Randal <allison.randal at canonical.com> 
> ------
> Packaging
> The application is well packaged using the Debian packaging system
> 
> -1
> 
> Still has problems with some fundamental Debian packaging elements
> (installing images in /usr/lib, no manpage for binary, etc). Commented
> in REVU that he "doesn't have time to fix the errors".

The requirement for a manpage for the binary is not useful to end users and I don't thing ARB apps should be required to have a manpage.

Does installing images in /usr/lib hurt anything? Are the images removed when the app is uninstalled? Pointing out packaging problems without showing the author how to solve them makes the review a source of frustration for the author rather than a source of encouragement. For frequently encountered problems we may be able to show how to solve them by pointing at documentation, but I think we have the responsibility to show the solution that would be good enough to get the app accepted. If the only harm done by installing images into /usr/lib is violation of FHS, I think we should allow it.

> ------
> Packaging
> Includes suitable Copyright and licensing content
> 
> -1
> 
> Debian copyright file does not mention files with a different owner and
> copyright. Some source files are listed as GPL 2.1, some are owned by
> Scott Peterson and appear to be MIT license. It appears that he's sucked
> in a modified version of another project
> (http://musicbrainz.org/doc/MusicbrainzSharp) and not mentioned it in
> the copyright file. Also another file copyright Novell
> (VolumeDB/DecoderUtility.cs), GPL 3 license is not mentioned in the
> copyright file.

I think we have to insist that the author promise the app is appropriately licensed and copyrighted. However, I do not think we should require the debian/copyright file to be filled out /at all/. For PPAs people assert that the content being uploaded is redistributable, but no checks are performed on the packages by human or machine. I believe we should handle  ARB apps the same, using an exception based process to pull apps which are pointed out to have licensing problems rather than preemptively auditing them.

> -------
> Run Test
> Does not perform any malicious actions
>    
> 0
> 
> Code review needed, of 1000s of lines of C# code.

I think this is one of the most important review steps we can take. Screening for malicious actions is the most useful thing we can do to protect the end users, this is much more important than file system layout or man pages or a tedious way of listing copyrights.

> ------
> (Added) Content
> Content is suitable under criteria of PostReleaseApps process
> 
> -1
> 
> - Installs outside of /opt.

I completely disagree that installing in /opt should be a requirement. This makes it harder for devs, not easier. This needs to be removed from the requirements for the ARB process. If we want things to be installed in /opt, I believe the only acceptable approach is changing defaults in the tools rather than enforcing via policy.

> - Pushing the boundaries on the "complexity" scale. Contains multiple
> library files, "theme" switching capability, 1000s of lines of code.

I completely disagree that any of these criteria (library files, theme switching, 1000s of lines of code) should disqualify an app.

What do others think? Does anyone know how we can amend the review criteria? Shane mentioned in another mail that nobody responded so he assumed the /opt requirement was dropped. I too disagree with the /opt requirement but I don't think non-response is an appropriate method for amending policy.

| Elliot Murphy | https://launchpad.net/~statik/ |