Re: Re: Request for ARB dependency rule changes
Copying back in the app-review-board to ensure everyone is on the same page. On 3 February 2012 13:46, Michael Hall 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 > 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/s
Apologies
I'm afraid I don't think I'll be able to make tonight's meeting; we're in last-minute baby preparation mode and I have some things to do that I really need the evening time for! I'll try to catch up with logs afterwards. Sorry, -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Fwd: Re: Request for ARB dependency rule changes
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 To: app-review-bo...@lists.ubuntu.com CC: mhall...@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 > 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
