Didier Roche wrote:
> Le 06/09/2012 10:20, Emmet Hikory a écrit :
> > 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.
This makes sense, although I think that we'd want to ask folk to sign
the CoC anyway, if for nothing else than to have their documented agreement
to participate in our dispute resolution processes, for those exceptional
cases where a problem occurs. Despite my agreement, I suspect that there
is significant scope for improvement of this hurdle through automation
without also forcing all participants to be subject to significant
limitations on the functionality they are permitted to provide, and believe
that as we develop the automation to support scalable automatic acception
of applications, we should do so in a way that permits us to use what
portions of that automation might reduce our educational requirements
independently of our automatic acceptance system.
> 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.
Absolutely. My apologies if I gave the impression that this should
be the typical model of inclusion - my intention was to use it as an
example of a package where there had been time for human review (which
we should only expect to be the case for a tiny minority of pacakges if
we wish to scale broadly).
> [F]or 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.
My concern here is that by maintaining entirely parallel processes,
we create a situation where those whose software is unsuitable for the
streamlined process must begin again, essentially from scratch, in order
to deliver their software to our users. I'd much prefer that in these
exceptional cases we had an integrated mechanism to assist the relevant
developers with the delivery of their package - to be able to provide
human review (resources permitting) and relax insulation restrictions
without ever needing to give the developers any message that could be
interpreted as rejection. Telling an application developer that their
application is special, and that we apologize, but they will either have
to wait for human review or limit the functionality of their software is
a positive and reinforcing message. Telling the same application developer
that their software cannot be accepted by this method, and they should
go chat someone up on IRC, or repackage the software and resubmit it to
some entirely other queue for which we won't hold their hand is less so,
and may well cause those very developers whose applications would most
enhance Ubuntu to discredit the process.
Similarly, I would hope that as tools are developed to further automate
the packaging process, these tools could be made available also to our
developers, who might use them in producing packages intended for the
current distribution mechanisms (where that distribution developer is
presumably willing to provide human review for their own pacakge, but does
appreciate the automation of the intial work).
> 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.
While I agree that we will need additional tools and an additional
delivery mechanism to support arbitrary application developers interacting
with an automated system to provide insulated pacakges to our users, I
do not believe we need a "different process", rather I submit that we
should rather be extending our general process to include the necessary
mechanisms to enable our goals, and that the new process elements that
we introduce by such extension be both compatible and integrated with those
process elements used to achieve other goals within our distribution. Yes,
this means that the process decisions involved necessarily impact the
distribution and our developers, but if we truly expected zero impact, why
would we be discussing this on the Ubuntu Development mailing list? Rather,
I believe we should focus on reducing the disruption, rather than the
impact in general (as we presumably want our users to be sourcing many
applications from the new delivery mechanism), and mitigating the risks
by discussion of foreseeable corner cases and developing a broad consensus
so that the extensions to our processes are widely accepted and supported
by the vast plurality of members of our community.
> 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.
I'm certain that most users don't care, and don't even notice from
which of the default repositories their applications are sourced: the
reason I feel that this is worthy of discussion is that I believe that
*we* care about from which archive we provide the packages, and if we are
to make the effort to extend the options available (and thereby extend the
classes of packages we deliver), we would do best to ensure that we do so
in a such a way that we have a consistent model explaining to ourselves
what goes where and why, as well as sensible mechanisms to move software
between different categories, as our needs as distribution developers
change.
> >>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.
I do not believe that we can do this completely. Even if we are able to
dispense with human review for 99.9% of available software, if we scale on
the order of 10^5, we end up with hundreds of packages that require human
review. My assertion is only that in such cases, we should have a clearly
understood mechanism to resolve these exception cases, and I suggest that
we use a streamlined integrated process of adoption as normal distribution
packages as a first-pass solution for these packages - once we have the
automation working, and have a better idea of the volume and nature of the
exception cases, we may decide that we need another category for software
distribution, but let's leave that until then, rather than deciding we don't
want to include software in the distribution simply because it could be
distributed using this new mechanism, or suggesting that we can't trust
some application developer to upload to Ubuntu simply because they are an
application developer, rather than for specific social reasons (e.g., we
don't believe they yet have the necessary skills to safely maintain their
packaging without the automation tools).
--
Emmet HIKORY
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
