Request for ARB dependency rule changes

[Jono Bacon]

Copying back in the app-review-board to ensure everyone is on the same page.

On 3 February 2012 13:46, Michael Hall <mhall119 at ubuntu.com> wrote:
> Please see the message thread below.  We are trying to find a solution
> that will allow independent Unity lenses and scopes while still
> maintaining the stability and maintainability of the extras repository.
>
> -------- Original Message --------
> Subject: Re: Request for ARB dependency rule changes
> Date: Fri, 03 Feb 2012 16:01:26 -0500
> From: Stéphane Graber <stgraber at ubuntu.com>
> We already discussed this a bit in #ubuntu-devel and #ubuntu-arb, so
> here's a quick summary of my opinion (which still hasn't changed).
>
> The restriction for inter-dependency of packages in extras was put in
> place to avoid cases where the depended upon package would become bad
> and need to be removed from the extras repository.
> It's also there to avoid potential breakage in case said depended upon
> package would be updated in an incompatible way by its developer
> (resulting in breakage for any of its reverse dependencies).

I agree with the technical premise of the rule, the problem we have
here specifically with lenses and scopes is that we have a large
collection of very capable lenses and scopes and a thriving lens/scope
developer community yet it is impossible for app developers to get
their lenses/scopes into Ubuntu because of this requirement (I think
these application developers are unable, and unlikely to pursue the
traditional core-dev/MOTU route of getting their apps into the
archive).

I would like to suggest we make an exception to this rule for lenses and scopes.

> I'd also add to these reasons, the incentive for important packages,
> which in my mind includes these packages that people want to extend to
> be instead uploaded to the main Ubuntu archive where they'll be easier
> to maintain.

I disagree. We should not expect app developers should be expected to
fulfill the expectations and requirements of an Operating System
integrator (such as a core-dev or MOTU) to get the content into
Ubuntu. This is why we created extras; we will never grow a thriving
platform for app authors if we expect them to meet the complex
requirements of core-dev/MOTU to get their apps in.

We built the ARB and MyApps process to provide an easier on-ramp for
app developers to get applications into Ubuntu, and the ARB was
specifically set up with the expectation that the packages would be
relatively trivial and small enough for review. I believe that lenses
and scopes are exactly this: they are small pieces of software that
bring real value to Ubuntu, and they are small enough for the ARB to
review.

> Extras is meant for "independent" packages (hence its name in the
> Software Center). Responsibility for the packages is on the developer,
> not on the MOTU/coredev team like it'd be in the regular archive, so
> there isn't a group of people doing QA/transition/fixes for these
> packages.

Agreed, but I believe that ratings and reviews provide a means in
which our users can express satisfaction and dissatisfaction with
these packages. If a lens or scope does not work well the reviews are
likely to chime in on this (which will dissuade users from using a
given scope/lens) and that package could potentially be removed or we
ask the developer to re-submit it.

As you say, we set up the ARB process to provide an on-ramp for
independent developers to be responsible for the content there (aside
from the acceptance requirements); I am suggesting we continue with
this, but relax the dependency issue which is currently blocking a
significant number of lenses/scopes from being released in the Ubuntu
Software Center, and let the users decide if the quality is too low on
a given scope/lens (we could also potentially mine USC data to
identify breakages).

> We already approved an exception to the rule by allowing a single
> source package to build multiple binary packages which then can depend
> on each other.
> This was approved as it was considered safe in that if we have to pull
> the source package out of extra (inactive developer or major issues
> with the package), all the binary packages would follow.
> That was also making it possible (still following our policy) for
> these packages to install files (in this case scopes) in existing
> directories (usually a reason for rejection) as these directories were
> created by binary packages coming from the same source.
>
>
> As I said on IRC, I'd clearly prefer each lens developer to be
> responsible for the scopes associated with it by having them send us a
> single source package containing all these scopes (aggregated from the
> community).
> This will follow our current policy as well as ensure good quality of
> the scopes as they'll be reviewed by the lens developer.
> This would also encourage a good relationship between lens developers
> and scope developers which I think would be in-line with the Ubuntu
> philosophy.

I don't think is practical. The beauty of the lenses/scopes model is
that a lens author could produce a lens that other developers add
additional scopes to. As such you may have scope authors who merely
plug their work into a lens, yet the lens author is not responsible
for their work. I don't think we should expect the lens author to care
about scopes that they are uninterested in.

> Just as a reminder, the ARB doesn't actually have the power to make
> any change to this policy, any change of policy needs to be discussed
> with the Technical Board.
> If you want to do this, I'd highly recommend sending the proposal
> today or be ready to wait an extra two weeks as last minute agenda
> items usually aren't welcome.

I am obviously not on the Technical Board, but I would like to find a
solution to this problem to unblock this issue with lenses/scopes. If
we can find an alternative solution to breaking the dependency rule,
that would be great, but I am just conscious that we can find a
solution.

I am interested to hear what the members of the Technical Board feel about this.

Thanks,

   Jono

-- 
Jono Bacon
Ubuntu Community Manager
www.ubuntu.com / www.jonobacon.org
www.identi.ca/jonobacon www.twitter.com/jonobacon