Request for ARB dependency rule changes

[Michael Hall]

Can we please have this added to the agenda for the next meeting?  We 
need a resolution to this sooner rather than later.


Michael Hall
mhall119 at ubuntu.com

On 02/07/2012 01:51 AM, Jono Bacon wrote:
> 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
>