Proposing a New App Developer Upload Process

[Didier Roche]

Le 05/09/2012 20:20, Emmet Hikory a écrit :
> Didier Roche wrote:
>> I don't agree it's only for low quality apps. More than once, people
>> asked me to package their apps into ubuntu. This is particularly
>> annoying when I have no interest at all in the package itself. The
>> last case is pyromaths, which turned out to be quite popular in
>> schools. It's definitively a quality apps and I kind of regret to
>> upload it to ubuntu proper instead of letting them deal with myapps
>> for now as I have to admit I won't do a good job tracking them.
>      In this case, do you see any reason that the developers of this
> package should not be able to be granted PPU access to keep their
> software well maintained in the archive now that it has been packaged,
> rather than being subjected to arbitrary restrictions on what the
> software may be allowed to do?

Because those developers are not interested at all at learning 
packaging. Today, the package is IMHO in a good shape as I've done the 
first pass on it.
However, their application is simple enough that this is typically the 
kind of application which can be package by python-mkdebian and I guess 
pkgme?).

Those won't produce perfect package of course (which is the standard we 
even have for universe), but workable upstream component that I'm 
totally confortable with (with insulation if the all process is 
automated without double checking).
>      If so, what do you think would be required for you to feel
> comfortable endorsing such a grant of access?  If not, why should
> any Ubuntu Developer refrain from such an endorsement if they
> consider the application well-packaged (either as a result of
> their collaboration or review of the packaging)?
>
>> The MyApps story is to avoid those 2 pitfalls to occur:
>> * having ubuntu developers working on what they want to work on and
>> focus their effort on that, following the components they selected
>> closely and be able to help them.
>> * having application developers being able to have the control where
>> they should have: their own applications and decide when they
>> update. We can enable them to update as long as they do no harm to
>> the platform (like in the file conflict case, and many other use
>> cases requiring insulation). The ultimate goal is that all the
>> packaging part is helped/assisted to them: it's not because I want
>> to upload my application to ubuntu that I have to become a packager
>> and know every detail of the debian policy. I just want to deliver
>> my application to users.
>      While these are both laudable goals, I don't understand why there
> needs to be such a firm separation between "packages that are in Ubuntu"
> and "packages that upstream authors may update".  While I am in favor
> of taking care to insulate our users from potentially malicious packages
> in the presence of a completely automated acceptance process, I expect
> that the vast majority of software authors would also be perfectly happy
> to be able to upload their software directly after receiving some manual
> review or assistance from someone knowledgeable about packaging, and I
> believe that we both can and should attempt to enable as many as we feel
> we can trust to do just this, rather than relegating them to some more
> limited packaging area just because we don't want to be personally
> responsible for the package.
>
I don't think we want right now touching soyuz and other distro 
components to introduce new services like automatic packaging, web 
frontend and other parts that myapps provides. I don't think we should 
have the upstream developer having to generate a source package on their 
machine, then knowing about dput to push it into the distro, our 
freezes, and other processes.

Also, there is this file conflict checker and restrictions for namespace 
needed if we want to automatically accept those packages. That's why for 
those kind of applications developers, we should segregate their apps 
into a different silo than the main distro one, as they have different 
process and requirements.

Didier