Serious concerns about ARB policy (was Re: Basenji)

[Shane Fagan]

Ok after actually reading the entire email ill give some replies. Im not
an athority but ill just say what my reply and hope that its correct.
On Sat, 2010-10-02 at 12:47 -0400, Elliot Murphy wrote:
> 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.
> 
Well im very sure that there is no manpage requirement in the spec so we
can just ignore that one outright. /usr/lib isnt any harm for this
release to allow IMO since /opt is out of the question till 11.04
because of various issues after that id expect everything to be in /opt.

> > ------
> > 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.
> 
The problem here is a few things. 1. we have to guarantee that the app
is appropriately licensed before the app is put anywhere near a repo to
cover our ass. Also if they are using patched together libs with
different licenses they might be incompatible with each other and thats
a problem with distribution too. 2. The app should where possible use
the libs in the repo rather than using insane hack jobs on libs and
patching together their apps with those. That one is mainly about
quality.

Of course us having to review each apps copyright isnt really what this
list is about but its still a -1 for any app that might have  any remote
distribution problems because of patchwork poor licensing. We cant take
any chances in this area.

> > -------
> > 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.
> 

Yeah I agree here and thats why I was taking my time with this one to
review it properly. This app is a special case though because it relies
on special libraries that it has. That results in a lot of code bloat.
For most other apps that this board will review should have <1000 lines
of code in the main project not including the setup files..etc.

> > ------
> > (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.
> 

I said on this list a few times but no one except Andrew talked about
it. The /opt is a good standard to follow but since we cant do that till
11.04 at the earliest because of various problems that arent trivial to
fix we cant switch yet. So I suggested pushing it to 11.04 and reviewing
the problem again if its still a problem. But I still think it should be
pushed in the future as a requirement. 

> > - 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.
> 


So to be clear id like to know if we can amend policy ourselves or do we
have to ask the TB for approval of changes in policy? We should change a
few requirements around obviously so we kinda need to know if we have
the power to actually change it. Elliot is entirely right in his
concerns and I think we should really have a proper discussion about the
requirements and see what is actually enforceable and what should be a
preference that is encouraged. 

--fagan