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
--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
