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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel