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