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? 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?
> >>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).
> 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?
--
Emmet HIKORY
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
