Fwd: Re: Request for ARB dependency rule changes

Fri Feb 3 21:46:18 UTC 2012

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>
To: app-review-board at lists.ubuntu.com
CC: mhall119 at ubuntu.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/03/2012 03:42 PM, Jono Bacon wrote:
> On 3 February 2012 12:37, Michael Hall <mhall119 at ubuntu.com>
> wrote:
>> We currently have over 50 different Lenses and Scopes being
>> developed to extend the functionality of the Unity Dash, being
>> made by more than a dozen different developers both inside the
>> company and without.
>> 
>> The design of the Lens API specifically gives these developers
>> the ability to work independently, but still allow their
>> different pieces to work together.  Lens authors don't need to
>> specify every available Scope written by other people, and Scope
>> authors don't need to submit their work for approval by Lens
>> authors.  It was very deliberately designed to allow this.
>> 
>> Now we want to start getting those 50+ additions to Unity
>> available to users through the Software Center, so we are having
>> them packaged and submitted to the ARB.  The issue we've run into
>> is that the ARB's currently policy does not allow different
>> source packages in the extras repository to depend on each other.
>> So while the Unity API has made it possible for me to write a
>> Scope without having to submit it to the Lens author for
>> approval, the current ARB rules won't allow it unless I get the
>> Lens author to include it in their own source package, or the
>> Lens package gets moved to the Universe repository.
>> 
>> Because of this I am requesting either an alteration to the
>> current ARB rules on dependencies, or an exception specifically
>> for Unity lenses and scopes, that will allow us to distribute
>> these valuable and popular enhancements to all of our users
>> through the Software Center.
> 
> I think this makes sense. We have an awesome stream of lenses
> coming in, but ultimately, there will be more scopes than lenses so
> this poses a challenge.
> 
> In terms of quality my view is that the Software Center is
> equipped with the tools for users to express dissatisfaction with
> the quality of something and that will help users to choose the
> best lenses/scopes. If anything really breaks we can always remove
> it and ask the dev to fix it.
> 
> +1 from me so we can get more content in the software center.
> 
> Jono

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

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.

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.

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.

- -- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPLEsjAAoJEMY4l01keS1n1jsP/2uEd1zcVfEdlJtLPLkfsnrZ
aFATbIyvk4boc7PEMGohdKonpwooenvFIcZRC22Ih+KVa09+ird9ASCRvChOdrg3
z8QDZxpMtF6zH6Y8Amj2xXWk6q4Svi+GMal7PJ6LasRu8WWW2l6l7VhmO2tTbaFQ
9M7NPqbwBq2DMW5Nh9qwf85bOgeJIWsOwYZwYABVgO3q+qOPahxX3iqzNJD7Rrj3
t+f/ZzbItZWdS39rBIn339d367RY1JMUuqEFmlLMeaBID96UkiF2hfaPYENflgzY
phB3giPzVibEgqZ+E0R3dsmBHdE3YXUTvQ4DvJjyrY9+q3d/Hs5JPa/lgjkDQISi
31cA4lsjjPzBouOw/aD22FMf5OrhU28HVJoJWAjNrP6aEkGrDVxeiai/xUEGcaAt
V+GWhbMENIlR3yVboHPn2E2OOZOtRWzPCWMH5sPN+S2WpLPdcerhbEz7dPOFQs13
opicy4W9FIoflClfO0Hi/WXzQwf7Qak2cXov2VEWdvWrP9rTnwm3+Xn4BkgIRSGB
K5J35Wovx8ey3RTQiB5LqRoUwzks1/Fg2KT25wTcriz4LCHpbadE2QbdLR4I9NwM
5pQTpOKdD5wD1ANf22oevSuO1xzjox6oyafOBMepRLnRD95tyuidzJFyaUWCHuJ1
ywLk8xsvADCYGxD/JIKg
=94D1
-----END PGP SIGNATURE-----