continuing conversation from UDS-N - Application Review Board

[Allison Randal]

We had two sessions on ARB today at UDS, one on policy[1] and one on
implementation/infrastructure[2]. There's one more session ahead on
sandboxing (on Thursday), but I want to loop the conversation so far
back around with those who couldn't attend or participate remotely.

On 13/10/10 20:16, Allison Randal wrote:
> * Should installing in /opt be a hard requirement? can we delay the 
> requirement until natty?
>    - The tools (CDBS, etc) don't make installing in /opt easy (and 
> NewApps specifically targets newer/less-experienced developers, not 
> packaging experts)
>    - Insufficient developer documentation on how to change manually 
> generated packages to install in /opt
>    - Some parts of the wider system where PostReleaseApps should 
> integrate don't look in /opt (menu doesn't look for .desktop files, 
> panel doesn't look for applets)
>    - An existing, successful PPA app has to reupdate/fork to comply with 
> /opt requirement.

The general consensus in the room was that the security and
encapsulation concerns that motivated the /opt install location in the
original spec are important enough that we should keep the requirement.
But, that we should also:

- put together a list of specific exceptions to the /opt install
location for cases where it's not currently technically possible to
install in opt,

- specify a convention for segregating files outside /opt into their own
namespace, with something like a prefix on filenames or subdirectories
within FHS,

- develop checks (and tools for automated checking) between apps that
install any files outside /opt and main|universe|restricted|multiverse

- work on the tools to make it easier to install in /opt,

- take a more hands-on approach in the early months of the new process,
and actively help developers with the move to /opt where it's possible
(with the note that this is feasible now with 4 applications to the ARB,
but won't scale to hundreds and beyond, so it's a temporary measure),

- at the same time, document the process of modifying an app to install
in /opt, to help developers.

> * Can or should we waive some ordinary restrictions of Debian packaging 
> for PostReleaseApps? (There was some tension here between wanting to 
> make the packaging easy for developers, but also wanting to respect 
> community standards, and protect the overall install of Ubuntu.)
>    - Should we require manpages for every binary? Are manpages likely to 
> be read for lightweight apps?

Generally agreed that manpages for GUI-only apps aren't critical, though
we can encourage at least stub manpages. Also, the tools can help new
developers here (Quickly already generates stub manpages).

>    - How stringent should we be about FHS? For example, are images 
> installed in /usr/lib an automatic rejection?

This is one of the things that the /opt install solves. It's not such a
big deal if an app installs images in (for example)
/opt/extras/myappname/lib as it is to pollute the global lib paths. FHS
is also a good area for encouraging developers to a better way.

Apps that install outside /opt will be required to respect the FHS.

>    - Copyright, require only PPA Terms of Use 
> (https://help.launchpad.net/PPATermsofUse)? Allow more relaxed rules on 
> copyright, possibly even skipping debian/copyright file?

The majority preference was to keep the debian/copyright file. Also, to
keep an eye on issues like license compatibility and clashes in combined
code, but not necessarily adopt the full extent of Debian
copyright/licensing policy. One important point was to make it clear to
developers that they are responsible for making sure that their code is
legal to distribute, and the ARB is here to offer guidance when we see
(potential) problems.

> * How complex is too complex for PostReleaseApps, and how to gauge it?
>    - Is 10k lines of code too great? How about >1k? Is lines of code 
> even a reasonable measure of complexity?
>    - Is bundling libraries from other projects (that haven't been 
> packaged on Ubuntu yet) acceptable? What happens when the library is 
> packaged later?
>    - Is complexity of features a reasonable consideration? (i.e. a 
> simple doc viewer might be fine, but OpenOffice.org should go through 
> the full REVU, etc.)

Lines of code or complexity of features aren't necessarily absolute
deciders, but may contribute to an overall sense of complexity.
Bundling libraries is something to discourage, but not necessarily
grounds for bumping an app to REVU.

The general consensus was the pragmatic perspective that since it's a
new process we should have the ARB go ahead and decide on some apps, and
loop back around with the whole community on the decisions made and the
reasoning behind them so everyone can participate in refining the
process. Particularly, if the ARB members are uncomfortable approving an
app, that's a good sign it needs wider discussion or the more extensive
REVU process. We also thought a "staging" process would be a valuable
addition, with delay between an app being approved by the ARB and going
live in the archive, as a good opportunity for broader community review.



We also talked about extras and backports, to summarize:

- It's currently not technically possible to selectively backport
individual applications, but there's work being done to make it
possible, with a UDS session[3] and work to be done this cycle. We are
definitely invested in improving backports.

- The problems with testing extras PPAs on ARM (lack of virtualized
testing capability, and the security risks of allowing random developers
full access to ARM test servers) can be alleviated if we have the ARB
members run the PPA tests on ARM, after a package has already passed the
other requirements and security checks.

- There was broad agreement that the Backports team and ARB want to work
closely together. There was a kind of "ah-ha" moment in the middle (with
eyes lighting up in both teams), at the idea of a kind of "virtuous
cycle" between the two where extras is a conduit for greater visibility
for new backported applications (but not libraries) and backports is a
path for popular/growing extras applications to take the next step
towards the center of Ubuntu and persistent inclusion in universe.

- Over the long-term, we expect that backports and extras will diverge
more, with extras focusing on the "easy on-ramp" for new developers and
lightweight apps, and backports focusing on making it possible to get
"early access" to full applications and libraries that are definitely
slated for a version update or new inclusion in the next release cycle.
Some things to keep an eye on are whether the two processes diverge as
much as we expect, or actually move closer (possibly as a side-effect of
the overall vision for the future of Ubuntu), and opportunities to
share/merge tools and procedures.



As a related note, mpt and ev gave a couple of fantastic keynotes today
on the future of application development on Ubuntu. The idea of "we want
to get to the restaurant" kept coming up in the afternoon session as a
reference to that vision of how we attract developers (the titles of the
talks were a clever play on Douglas Adams' "The Restaurant at the End of
the Universe").

Allison

------
[1]
https://blueprints.launchpad.net/ubuntu/+spec/ubuntutheproject-community-n-app-review-board-review

[2]
https://blueprints.launchpad.net/ubuntu/+spec/appdevs-desktop-n-opportunistic-apps-stable-release

[3]
https://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-backports-notautomatic