Scott Kitterman wrote:
> On Thursday, September 06, 2012 04:14:40 AM Emmet Hikory wrote:
> > To avoid conflicts of interest, I suggest that agreeing that the
> > content of the repository to be populated through MyApps is to be treated
> > as part of Ubuntu is a prerequisite: otherwise there is too much potential
> > for those Ubuntu Developers who have decided to entirely ignore the presence
> > of a third-party external repository called "extras" to complain that their
> > upload is unreasonably blocked, and no sensible conflict resolution path
> > due to the lack of a common authority other than sabdfl.
>
> That's not the only way to solve the procedural problem. It's been
> established that the Ubuntu technical board has the authority to set policy
> for the Canonical Partner archive. I have assumed that they do for extras as
> well. If they don't, that can be fixed without redefining what is part of
> Ubuntu and what is external to it but related (for those unfamiliar, Partner
> is served from a different archive (archive.canonical.com) and not formally
> part of Ubuntu).
Ah, if the partner precedent is extensible also to extras (and it may well
be given that the ARB has often referred to the Tech Board to take decisions),
then that also satisfies the prerequisite, so that in the event of conflict,
there is a means to request external resolution (either from the Tech Board,
or, if this becomes a significant burden, from some delegated authority),
which we might reasonably expect to be binding for Ubuntu Developers.
Independently of the conflict resolution model, I still don't understand
why we would need to consider such a collection of software "external",
beyond the historical precedent: is there a reason we want to prevent an
interested Ubuntu Developer from fixing a bug in one of these packages?
Do we feel that having two clearly documented competing different processes
for the inclusion of software will help our users to be able to run the
software they prefer? Do we want to prevent upstream developers from being
able to maintain their software as part of Ubuntu? Should flavours be
restricted from seeding packages submitted by the original developers
unless they are willing to override the upstream submission?
Yes, there are trust issues, especially if the submission is the first
time we encounter some developer, but these can be handled by limiting
what their software is permitted to do, without necessarily resorting to
banishing the software from Ubuntu, and doing so in such a way that also
delivers it to users to that later inclusion in Ubuntu may require even
more discussion and coordination than has historically been required,
rather than just a shift between different parts of Ubuntu as the
necessary trust is established.
> FWIW, I think it's entirely appropriate for Ubuntu developers to not be
> overly
> worried about third party repositories. Any solution that requires them to
> be
> concerned will drive Ubuntu to a forked namespace with Debian and that will
> be
> a fundamental change in the way the distribution works that I don't think we
> want.
My apologies if I created this impression: while I agree that we should
impose no requirement that Ubuntu Developers be aware of the content of
arbitrary third-party repositories, I believe it is in our interest to both
have a clear means in place to resolve potential conflicts resulting from
those third-party repositories we have agreed to present to users as
potential defaults, and to follow namespace claims for what we might expect
to be promoted as "the way" to request that software be made available to
our users by the developers of that software. Of course, if the inclusion
requirements for such a third-party repository are such that it prevents
any namespace claims, then there is no need to be concerned, but from the
discussion so far, I don't believe we will reach this during the quantal
cycle.
--
Emmet HIKORY
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
