Packaging branches which are not owned by ubuntu-dev

[Emmet Hikory]

Siegfried-Angel wrote:
> There are (and I guess in the future this will be more frequent)
> branches for Ubuntu packaging which are not owned by ubuntu-dev. As an
> example, the Mythbuntu team maintains several mythbuntu- packages, as
> you can see on https://code.launchpad.net/mythbuntu; I'll continue
> referencing this case in the remaining part of this e-mail.
>
> This raises the problem that Ubuntu Developers can't commit to those
> branches, which I want to solve by starting this thread. The possible
> solutions I can think of are the following ones:

    I very much don't see this as a problem.  I've reviewed packages
for several flavours (and proto-flavours), and worked with the
relevant packaging teams to get the packages into Ubuntu (including
mythbuntu).  I feel fairly strongly that if a package is actively
maintained by a development group associated with a flavour
(especially a flavour approved and supported by the TB (currently
including Ubuntu Desktop, Kubuntu Desktop, Ubuntu Server, Edubuntu,
Xubuntu, Ubuntu Studio, Mythbuntu, and Ubuntu Mobile)), it is
appropriate to get agreement by that team prior to changing the
package.  Where an existing member of ubuntu-dev wishes to join one of
those teams, I expect they would be welcomed.  Where a member of
ubuntu-dev who wishes to change one of those packages but not
participate in the team, I think it appropriate that that person
contact the team to ensure the changes are acceptable prior to the
upload.  The current structure of permissions in Lauchpad supports
both of these use cases well, so I don't see any reason for the
change.  Note that although there is currently no active support for
gobuntu, ichthux, or ubuntu-me, I believe the same guidelines ought
apply to Ubuntu Developers making changes in packages specific to
these flavours: it is only polite to ensure that those working on
flavours of any status be involved in discussions of changes to
packages which directly affect the flavours concerned.  While this can
complicate NBS, the development groups of each of the flavours
(official or not) has in my experience been fairly responsive to
engagement, and none claim packages that are not core concerns for
them, nor for which active maintainance and support is not provided.

    Further, while I support Mythbuntu, and think it provides a useful
collection of software, it would be inaccurate to say that I am a
Mythbuntu developer.  WIth any structure that causes me to indirectly
be a member of the mythbuntu-dev team, LP will inaccurately represent
me as a Mythbuntu developer.  While this may be a boost to my ego, it
devalues the presence of the emblem for those who are truly developers
of Mythbuntu.

    Lastly, with active discussion on ArchiveReorganisation (1), I am
very uncomfortable with wider changes to the way in which teams are
structured without reference to the existing specification, or
consideration of how these changes might affect that implementation.
It may be that this change is appropriate within that context, but it
may equally be the case that it is not appropriate: it would benefit
from wider discussion prior to implementation.

1: https://wiki.ubuntu.com/ArchiveReorganisation

-- 
Emmet HIKORY