Allison Randal wrote:
> Here's my perspective, in short form:
>
> - Extras is PPU + Backports + training wheels.
>
> - Extras is a place to experiment with how the training wheels should
> work, without disrupting the main archives.
>
> - Eventually Extras should go away, once we've extracted the best value
> from the experiment.
While this makes sense, I think that if we want extreme scalability,
we would need to have somewhere with the training wheels firmly bolted
in place, as there are likely many possible programs that simply will
not notice or care if there are limitations to their activities as a
result of our efforts to insulate our users, and if we can create the
appropriate mechanisms to protect Ubuntu systems, I see no technical
reason not to provide for an entirely automated application submission
and acceptance process, but I do believe that such a process should
place the results in a separate repository or component or something,
because some of our users may wish to intentionally block such packages
from being made available to their systems.
I do think that we would do best to have whatever location we decide
to be appropriate for the automatically reviewed and approved pacakges be
something we consider part of Ubuntu (as distinct from how extras is today),
as I believe the separation of this project from Ubuntu proper does little
to ensure close integration while being a meaningless distinction in the
perception of our users.
It is worth noting that it may not be possible to have a completely
automatic process, as those who would redistribute the content may be
limited in some ways in terms of what content they can redistribute, or
to which locations they can redistribute that content, but these are
social and legal issues, rather than technical, and best handled by
asking those we would expect to redistribute the content to determine,
rather than attempting to construct a process that requires human review
because there may be an issue: there are enough existing means to either
create an artifical interruption between acceptance and publication or
cease the distribution of a package that we can surely allow the
distributor to make the appropriate choice as part of the deployment of
whatever implementation we agree upon.
> These are what I consider to be the most crucial immediate questions:
>
> - Should we change Extras operation so it's less like REVU (approving
> each package) and more like PPU (approving a particular developer for a
> particular package name)?
I would prefer to answer this question with "No", for three distinct
reasons. Firstly, I believe strongly in peer review, and think that any
package that anyone submits should be reviewed *as a package*, and secondly
I don't think we want to mix our conception of code and people: bad code
from good people should be fixed before being provided to our users, and
we should be able to accept good code from those who we might not want to
immediately grant upload rights (given an acceptable compromise to all
concerned).
One of the issues previously found with *any* of the review-based
systems was that packages would sometimes fall into what seemed to be
an endless submit-review-resubmit-rereview... process. During the more
active days of REVU, we experimented with collaboration for the packaging
of a few packages, with each reviewer fixing all the issues they could find
in the package, and resubmitting, but this collapsed due to disagreements
about the credit for the work done: if we can find a way to appropriately
show the various contributions of collaborative initial packagers, such an
approach would likely significantly reduce the apparent difficulty of
accepting manually reviewed packages and help introduce those submitting
packages to the collaborative workflow commonly used in Ubuntu.
So, thirdly, I suggest that if we start approving applications
in a per-person manner, rather than a per-application manner, we limit
the potential for pre-inclusion collaboration: this ought happen *within*
our default submission tools, rather than being something that needs to
happen externally. I also believe that in cases where there was such
collaboration, we would want to have the set of folk to be granted PPU
rights for the package based on the final outcome of the packaging,
rather than the identity of the initial submitter.
Note that I consider this "No" to be only applicable for manually
reviewed packages: where we can provide mechanisms to protect users and
allow automated review, I think we ought automatically grant upload rights
for the package to both the submitter and anyone else already able to upload
to any unseeded package.
> - Should the DMB be made responsible for approving those Extras PPU rights?
If we are to use the PPU mechanism (which seems appropriate to me), I
believe that only the DMB can be responsible for the oversight of granting
these rights: anything else ought involve a deeper discussion of the role
of the DMB and how we wish to manage upload rights in general.
That said, from my previous work on the DMB, I think that we would
need to ask the DMB to develop a lightweight PPU-only process to scale
significantly, as the processes in place during my tenure would be
unsuitable for use if there were a significant number of submissions
by such a new process.
Note also that if we decide to use the DMB and the PPU mechanism, we
would likely be expected to have extras be part of Ubuntu, with all that
this implies in terms of other goverance issues *OR* have packages accepted
by such a means be placed in the regular archives (and thereby be
expected to be policy compliant and treated as normal packages aside from
the submission process and PPU).
> - Should we remove the /opt install requirement?
This is just an implementation detail of our current insulation. While
it is the FHS way and used widely in commercial packages for other unices,
I don't believe it is useful to discuss in isolation, and I believe very
strongly that if we do decide that it continues to be a useful mechanism
that we ought modify our tools so that the application developers need not
care precisely where in the filesystem their applications are delivered.
Obviously, there exist some applications that are unsuitable for any
sort of /opt jail, but I believe these to be few enough in number that
we can spare manual review to allow them to be installed without insulation.
(which likely means not in "extras" with the current implementation).
> - Should we start developing tooling for more automated package
> checking/sandboxing?
Absolutely: we have a limited capacity for human review, and we can
likely safely say that there are always going to be more people who are
interested in writing software that does something than are interested
in reviewing the software and the packaging for that software, and there
are *lots* of sorts of software that will operate perfectly within a
highly restricted container, for which we ideally would be able to
dispense with human review.
In cases where we need human review (either because our automation is
not yet sufficiently mature or the package appears unsuitable for automated
inclusion), I think we need to be flexible about the restrictions we impose:
unless we are particularly unable to select capable reviewers/collaborators,
we should allow the reviewer to decide if a package needs to be limited in
some way, or would benefit more from normal inclusion in the distribution,
and empower that reviewer to implement their decision directly, without
being subject to further review (with the possible exception that if there
are sufficient resources to permit peer review amoung reviewers, this would
be a good thing), and most importantly, without the application author
needing to resubmit to a separate queue with completely different
requirements.
> My ideal future looks something like: Debian and Ubuntu co-habiting on
> DebExpo (either on mentors.debian.net, or two sites with federated
> data), with a slick UI, and fantastic integrated tools for automated
> package checks. But, there's a lot of development work between here and
> there, I can't just snap my fingers and make it happen tomorrow.
I don't believe this is sufficient for truly extreme scaling. While
something of this sort would greatly facilitate anything that would benefit
from human review, I am unconvinced that we have sufficient humans willing
to review things that an ideal future would not also require the completely
automatic acceptance and inclusion of packages to be placed under a set of
restrictions that we agree is sufficient to prevent damage to our users.
Obviously, for extra points, these automatically accepted packages
ought also be available on the super-debexpo as potentially suitable for
manual review either because they are really cool or because the vast
number of reviewers are becoming bored as a result of having completed
the collaborative packaging and inclusion of all packages that required
manual review.
--
Emmet HIKORY
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
