Juju Delegated Team

[Robie Basak]

Hi Nicholas,

Thank you for looking after the Juju-related packages for us in Ubuntu!

In the past I have worked very closely with Juju upstream on these
packages myself, including considerable time and sponsorship. I haven't
touched or looked at the packages this year though - in particular not
Juju 2 at all.

On Thu, Aug 11, 2016 at 03:18:46PM -0400, Nicholas Skaggs wrote:
> I would like to request a delegated `juju` team for the juju set of
> packages. By definition this set of packages would compromise of any
> package that contains code the juju-core team releases (
> launchpad.net/juju-core), or a package that is primarily consumed or
> utilized by the juju-core package.

I think we should certainly consider creating a packageset, and I have
no objection to this in itself. However, see below.

> https://wiki.ubuntu.com/balloons/DeveloperApplication

I see this is scheduled for today, but I don't see any endorsements on
your application. Do you need more time? In any case, it might be worth
discussing what I've written below in our meeting today.

A PPU for these packages makes me hesitate, based on my own experience
in the maintenance of these packages.

The packages are not straightforward at all from a standard packaging
perspective. For example, there's static compilation and its security
implications, the embedding of third party dependencies, changes to
those dependency needs impacting SRUs of major release updates to stable
Ubuntu releases and the need for the separate juju-mongodb* packages.

I also spoke about plans on dealing with a required intermediate MongoDB
version shipped in an extra juju-mongodb-* package to handle an upgrade
path, though I'm not sure what happened with that in the end.

This isn't an exhaustive list; there may be other issues of a similar
unusual nature that I haven't remembered right now. The need for your
recent post on the ubuntu-release mailing list is I think a good
demonstration of what I mean (you did the right thing by bringing it
up). It is as if everything in debian/* is special somehow!

I feel that to handle these issues well needs significant experience -
at the level of the TB, release team or archive admin teams, and
certainly nothing less than a core dev. For example, when I was a
sponsoring core dev for these packages, I was in constant contact with
current and former TB and archive admin members over these issues. Hence
my hesitation with regards to a regular PPU for these packages. I'm
interested to hear other DMB members' opinions on this.

On the other hand, I appreciate the need for regular minor bugfix
maintenance in our stable release, that they don't touch any of the big
scary packaging pieces, and that requiring sponsorship for these uploads
hinders progress. I would be comfortable in granting PPU for this class
of upload (subject to individual merits).


I wonder if the DMB can consider granting upload access to these
packages on the condition that this is for bugfix updates only that do
not involve decisions on how to handle these special cases? I'd expect
anything else to still be reviewed and sponsored by a core dev, having
consulted with the release team or TB as appropriate.

Would this be useful to you? If you have any thoughts on my concerns
above, including any alternative way forward, then I'd be happy to hear
them.


Some other notes.

Does a packageset still make sense? I guess that depends on how we
decide to resolve my concern, so maybe we should decide what we're doing
with that first.

For Michael Hudson-Doyle and Adam Stokes to be on this proposed team is
effectively a no-op from the DMB's perspective - as they're already core
devs, they can already upload all of it. If they'd like to be explicit
members of a DMB-managed PPU team for social reasons, then we can
certainly do that assuming everyone involved is fine with it. I would
propose a DMB vote to make it "official" but I see no need for
individual applications.

Robie