Summary of concerns with post-release applications

[James Westby]

Hi,

In an attempt to aid the discussion I would like to summarise to the
best of my abilities some of what has been said so far. My hope is that
this will help focus the discussion around specific areas of concern,
and try and avoid people talking past each other.

My aim is not to advocate for any particular position, but obviously I
can't write without some form of bias. I have attempted to keep my
opinions on the matter to the editorial sections (I couldn't possibly
keep my opinions to myself for as long as this took to write). My
apologies if you feel that I have misrepresented your position, and
please feel free to reply with corrections if you think this is the case.


== Goals ==

There are several, overlapping, goals of the process that is being
defined.

1. Allowing developers to target a stable platform.
   - As it stands you have to target a fast-moving platform, the
   development release, which can be time consuming. Instead some
   developers would like to target the stable release, where they have
   known versions of components that they rely on.
   - This doesn't help them in preparing for the next release, where the
   "continuous integration" of testing on the development release may be
   an easier way to go.

2. Allowing developers to get to where the users are.
   - With the current process you are 3-6 months away from having your
   code in the stable release, where most of the users are, unless you
   use backports.

3. Providing a way for applications to be discoverable by the users
   - Currently, if you are in the stable release then your app can be
   found. However, if you are using backports then your code isn't easy
   to find by someone search software centre for a game or whatever,
   as it is not enabled by default (and it may not be included in
   app-install-data very regularly?)

4. Giving developers more time to get their application included
   - Currently you have around 3 months to get your application included
   in the development release. It is in fact more, but it gets harder
   and harder as the cycle progresses.

5. Providing an easier way for developers to get their application
   included
   - The current process is fairly tough for people to go through.
   Firstly there is a perception that the checks are too rigorous, at
   least for the class of package that most people are talking about in
   the process. Secondly, the number of people reviewing proposed
   packages is too low, and so it can be a lot of effort to get the two
   reviews needed.

6. Create a process that is easier to sell to application developers.
   - This one is a little more subjective, but it has been suggested
   that the new process will be an easier sell to many developers who
   have typically not worked with us.

7. Having the developers of some apps care for the distribution of it
   - There were some sentiments expressed around wanting developers to
   take care of the apps, rather than having MOTU do it for all the apps
   in universe.


--- Editorial ---

1 and 2 seem fairly uncontroversial, and I applaud the efforts to tackle
them.

3 could be solved without this new process, with some improvements to
backports that have been talked about for a long time.

4 could be solved just by explicitly allowing this class of package at
any time in the release cycle (barring the last couple of days of
release or whatever as needed)

I strongly agree with 6, but perceptions about the existing process
don't mean that we have to throw it out entirely.

Getting invovled developers to take away some of our workload certainly
sounds like a good idea to me.


== Concerns ==

1. Splitting the review effort.
   - We already have a group of people that review new packages and
   backport requests, and they are already overstretched as it is. There
   is concern that a second effort will split the number of people doing
   this and so make at least one of the efforts falter.
   - A sentiment was also expressed that getting people excited about
   this may lead to more people to review, rather than the same number
   spread across two teams.
   - With 11 days until the deadline, there are currently only two names
   on the wiki page of applications to join the board.

2. That it will "punish" people who run the development release.
   - There was a concern expressed that it might be a disincentive to
   run the development release, as these new applications that are
   presumably very cool won't be available there.

3. Buggy applications giving Ubuntu a bad name
   - Concern has been expressed that these applications could be buggy
   and so give Ubuntu a bad name.
   - It was said many times that the review requirements will be lower,
   so buggy is certainly more of a possibility.
   - It was said several times that we shouldn't think of them being
   part of Ubuntu.
   - They will however come from "extras.ubuntu.com", have gone through
   an Ubuntu process, and be featured in the "Ubuntu Software Center"
   - In the Software Center they will be in a separate "Independent"
   entry on the left, but they will be aggregated with everything on the
   "front page." I don't know what differences there will be when you
   look at the "app page."

4. Security with these applications installed
   - There were concerns expressed about security and these packages,
   both on the rm -rf / level, and on the user data security and privacy
   fronts.
   - I haven't seen any discussion about these issues.

5. That the plan is immutable now, despite it being different from some
people's recollection of the discussions.
   - On a different tack, but it has been said that it is near
   impossible to change anything now as some of the implementation is
   already done.
   - This implementation was said to be based on specs arising from
   discussion at UDS.
   - Some people have a different recollection of the outcome of the
   discussions at UDS.

6. That some of the discussion happened on the TB list without many
developers knowing about it.
   - While it was accepted that the TB should have been involved, many
   developers were suprised to find out about the process, indicating a
   communication mis-step at some point.
   - Relatedly, better summarising the discussions had at UDS for those
   not present was agreed to be something to work on.

7. That morale of Ubuntu developers will be negatively impacted.
   - Laney suggested that creating a new process to "route around"
   Debian/Ubuntu would harm the efforts to build a community of
   developers for the distribution.

8. Putting the application in to Ubuntu could cause conflict
   - Laney suggested that there is a disincentive to get your app in to
   Ubuntu, which I agree with, but I think that if it available for
   every release with apt-get from the default install there is little
   practical difference.
   - However, it does raise an interesting point. If I, as an Ubuntu
   developer, like one of these apps and put it in Ubuntu, then by the
   rules of this process the developer won't be able to get their
   versions in to the next release in this "lightweight" manner, which
   may cause conflict.

9. That the reviewers may not be Ubuntu developers
   - There was concern expressed that the reviewers may not have
   demonstrated their ability to create and review packages by becoming
   Ubuntu developers, the usual bar that we set for reviewing code that
   users will run.
   - I saw no response to this,

10. That the apps won't be automatically forward-ported
    - There was concern that as the apps won't be in the development
    release, and apparently won't be automatically forward-ported to the
    new release users may have a shock on upgrade, either removing the
    packages, or having broken apps.


--- Editorial ---

On the question of buggy apps, in some sense users won't care where it
comes from, so Ubuntu will often be blamed. They will however tend to
prefer a great selection of apps with a few buggy ones to none at all.


== Suggestions ==

There were a couple of suggestions that were made, beyond those
implicitly included above:

1. Sandbox these applications
   - Run the applications with limited priveleges so that they can't
   abuse the system or the users data.

2. Don't use Debian packages for these things
   - mvo has talked about "proto-packages" before, that e.g. don't have
   maintainer scripts. This would at least remove one of the easiest
   ways to do things as root and so lessen the review burden, but
   doesn't approach the problems of protecting user data and privacy.


== Overall thoughts ==

I think that moving in the direction of Ubuntu being the base OS, the
platform, and the applications being treated differently is the right
thing to do. However, we have some difficult questions around splitting
things up between the two categories.

For instance, consider a firefox plugin, it's a "leaf app" by the
current definition, but could ruin your browser experience. However,
people will routinely download them directly from mozilla etc.


There has also been a lot of disdain exhibited in this thread for Ubuntu
processes that have grown over the last 5 years. While we should
continuously examine and refine our processes there is a certain level
of process that we have to expect.

While many want to define a "lightweight" process, it will be tough to
maintain that over time, especially if the process becomes as important
as those same people hope. In 5 years time we may have a group of people
ridiculing the bloatedness of this new process.

Thanks,

James