Steve Langasek wrote:
> > On Wednesday, September 05, 2012 12:11:18 AM Emmet Hikory wrote:
> > > For application developers who prefer standard locations, I don't see
> > > any reason we oughtn't simply add their packages to the repository with
> > > immediate backport: in addition to allowing application developers to put
> > > their files in any policy-compliant location, it automatically provides a
> > > safe upgrade path for users. Even for software with release cycles that
> > > require significantly more frequent updates than typically provided by our
> > > release cycle, there are few barriers to keeping this updated in
> > > backports,
> > > and users who have installed from backports will remain with backports, so
> > > their most active and interested users may be expected to always have the
> > > latest version, while highly conservative users will be able to enjoy a
> > > consistent ABI during the life of a given release (although these users
> > > would need to wait for our next release before using the package).
>
> There's a general sense that the Ubuntu archive can't scale out to the
> degree it needs to in order to take on the next challenges for the platform.
> While Debian packaging isn't hard for you or me, and while it's definitely
> gotten much easier over the past 4 years or so, it's still not so easy that
> we blindly trust outside contributors to get the packaging right without
> review by an Ubuntu developer. We do not have an infinite supply of Ubuntu
> developers to do this review. Should the set of software available to
> Ubuntu users through apt be limited to only that software that Ubuntu
> developers (or Debian maintainers) have time and interest to take care of
> directly? Or should users have better (not perfect, but better) ways to
> install software that's not gotten the attention of the elite inner circle?
This needn't be an XOR model. Taking as given that our application
acceptance model has not only failed to scale, but has actually become less
efficient over the past couple years (roughly lucid through precise), and
that we *must* come up with a way to ensure that our users can easily get
new software in a safe manner (as opposed to use of random PPAs, arbitrary
third-party archives, random downloads and local compilation attempts, etc.),
we need not decide that this cannot interoperate with the existing processes
by which we add new applications, nor that the existing processes are now
inflexible to the point of no utility.
Historically, the limitation has often been insufficient reviewers, and
automation is a wonderful way to remove this, especially in combination with
sufficient insulation of the application from the rest of the system. That
said, we oughtn't force *all* applications to be so limited: there are many
tools that we would welcome as regular packages, assuming we had reviewed
them. Of course, unless we take care to ensure that, from the perspective
of the application developer, the process for having the package included is
very similar (and most importantly has the same widely-publicised entry point),
we only create division: random arguments about the "best" way to submit
packages in places we fail to see, people deciding not to submit because they
are unsure, or feeling rejected by one process and not wanting to start
another.
So, if we encourage the development of portable applications, and create
automation that can accept these packages, perform (limited) review, and wrap
them in sufficient insulation before presenting them to users, we should be
able to almost completely remove the requirement for human review (although
there are complexities that may require a lightweight gatekeeper check to
avoid repititions of the hotbabe discussions or similar). That said, if an
application fails the automated insulation testing or requires deeper
integration with the system, we should make it immediately available to
human reviewers who would be empowered to accept the submission as a regular
system package.
For those applications requiring insulation, the use of the extras
repository is likely the simplest route, although I'd personally prefer
that if we do this we either claim extras to be part of Ubuntu (and place
it under similar trust metrics), or create a new repository that we then
consider part of Ubuntu. For those applications requiring human review,
I don't see any reason we shouldn't strive for them to be included as
part of the regular repositories, and suspect backports is the appropriate
way to do this (although this may require some streamlining of the backports
process for *entirely new* packages, if we find that this is a blocking
factor).
Where this becomes complicated in when we think about trust: who do
we trust to perform the human reviews? Do we trust application developers
who received human review to update their packages responsibly? If we
wish to scale, I believe that we need to answer the first with "Ubuntu
Developers": if we have people sufficiently active in the Ubuntu Community
that we might accept them on a review board, and we believe them capable
of performing a review, I don't see any reason we shouldn't trust them
as much as we trust current developers. Similarly, if we don't trust
someone on such a review board to competantly review a package, why are
we willing to accept them on a review board? Further, do we truly wish
to restrict reviews to a small number of people rather than any or all
of our current developers, and do we expect that such a restriction will
help us to scale the inclusion of new applications? Again, in the interests
of scalability, I think we need to answer the second question with "yes":
we may require such developers to agree to some submission terms, and
to the Code of Conduct before we do so, but if we either 1) exclude
those developers with more complex applications from participating in
the maintenance of their software or 2) grant greater privileges to those
developers who submit to the insulation mechanisms, we discourage direct
participation in our development processes, and are less likely to grow:
there are certainly several current Ubuntu Developers who originally
came as upstream for one or another package, and began to care for more,
and I suspect the more we foster such inclusion, the more other folk who
are not upstream developers will also feel welcome to participate in the
development of Ubuntu.
--
Emmet HIKORY
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
