Proposing a New App Developer Upload Process

[Didier Roche]

Le 06/09/2012 10:20, Emmet Hikory a écrit :
> Didier Roche wrote:
>> 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).
>      Given the current shape of the package, and the belief that packaging
> of this package could mostly safely be completely automated, would you
> expect that future uploads would be broken in some way so that these
> developers would be incapable of performing the maintenance?
I think they should be able if I teach them about debian/changelog, 
dpkg-buildpackage, dput, gpg keys, signing the CoC… So even after the 
first upload, if they have PPU access, the bar to upload a new revision 
will still be high, even if there is no packaging changes to do.

In addition to that, as you told, the packaging is now done, but it took 
months for me to take some spare time to get to their package because of 
the queue of people asking me to package a new software is high, and I 
have other work to do for my direct work/life… So if relying to a human 
review or human first packaging from upstream will always take a lot of 
time (despite heroic effort on REVU, on the ARB, sponsoring queue…) and 
will give them a suboptimal first experience to deliver their 
application to ubuntu.

>    Not being
> perfect is fine (we have *lots* of packaging bugs; while we want all
> the packages to be perfect, this is a matter for ongoing effort, rather
> than a hard goal that must be met prior to distribution - the perception
> that it must be perfet to distribute likely stems from efforts by various
> reviewers to address as many packaging bugs as possible before distribution
> in the hopes of reducing later bugfix effort).
>
>>>      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)?
>      I still don't understand what you believe would be required for you
> to feel comfortable with the original developers maintaining their tool
> in our repositories.  Is it that you would want them to learn packaging
> in a general sense, or am I overinterpreting your comments above?
We have multiple tools, process for uploading packages to the distro. 
Let's agree that most of them are suboptimal and takes time to grap them 
(I'm always amazed when I explain basics of packaging to newcomers 
either at Canonical or to mates how we succeeded to make things that 
ought to be simple really complicated). And I think that's ok: debian 
inheritage showed and benefited us with years of experience, tackling 
all the corner cases to deliver a strong a coherent distribution, and so 
we need that complexity, especially for low level plumbing and librairies.

However, for applications, I think we shouldn't make everyone paying the 
high learning curve to developers. If they want to focus on packaging, 
we can direct them to this process, but if they don't, we need an easy 
way which have different tools, processes and reactivity. Those would of 
course, not cover the whole set of cases we can into the distro, but 
will deliver a snappy experience, which as much automation as possible 
on both packaging and server-side checking, in addition to insulation to 
protect our users.

>
>>>> 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.
>      Absolutely.  I entirely agree.  This in no way helps me understand why
> there needs to be the separation.  For those packages for which we can spare
> initial human review time, is there a reason we should not allow the MyApps
> submission framework to produce uninsulated packages suitable for direct
> inclusion?  If we happen to be in freeze, we just don't publish the upload
> to the development release until the freeze lifts (although we likely want
> to proceed with any related backports in a more timely manner).

I think I mostly answers this point on my previous comment, I strongly 
think that different process and scopes will need different tools and 
so, delivery mechanism. In addition to that, the tools will evolute 
quite quickly at the beginning, and we need to be able to change those 
without risking/impacting the distro and ubuntu developers.

btw, I think most of our users don't care about which archive the 
applications come from, so I'm not even sure the debate is rightly 
settled here.
>
>> 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.
>      For applications for which we are unwilling or unable to perform
> human review, I can see that argument.  For this specific package, where
> you have performed this review, why do we need to continue the segregation?
>

The argument is to completely remove the human review I guess.

Didier