Juju Delegated Team

[Nicholas Skaggs]

On 09/12/2016 11:16 AM, Robie Basak wrote:
> 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.
Indeed, I'd like to discuss and get some traction on this today. It's 
not blank anymore :-) I'll chase those who I've asked for endorsements 
again to fill it further.
> 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.
I absolutely agree with you. The reason for including Adam and Michael 
on the team is for this very reason. These packages are not easy and I 
felt it important to recognize they really require a team of 
knowledgeable folks to care for them. Because of there complexity and 
importance I also would advocate for a team to look after them to ensure 
we aren't siloing knowledge and/or the distro isn't wholly dependent on 
them. Finally, this allows for an upstream member to play a role in 
packaging juju inside of the distro. This is desirable for both parties.
> 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).
Yes, the biggest pain points are trying to help perform SRU's and 
ensuring timely minor release updates. Having more eyes and capable 
members to help with this would be a welcome thing.
> 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.
My expectation around non-trivial package uploads for these packages is 
to get consensus within the team, and often with the release and SRU 
teams, even the TB as needed. I think you can see I've personally tread 
these waters many times already in ensuring the resulting uploads are 
amiable to the those who are responsible to care for and look after the 
distro as a whole. While not opposed to this sort of conditional access, 
I feel upload rights are simply a part of the responsibility of the 
team. In the same way you would expect a core developer to raise issues 
which affect the greater distro ecosystem before uploading, I feel this 
team would have that same responsibility and trusty extended to them. A 
team member who violates this would lose these rights and trust, and 
ultimately the team may lose rights should fail to be a trustworthy and 
good citizen.
> 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.
Yes, it's effectively a social thing. These folks have the rights 
already, but as they have played a large role in helping maintain and 
sponsor uploads on these packages, it makes sense for them to be a part 
of the team. And as noted above, it's an important part of my appeal to 
the DMB to grant trust in a delegated team with full rights to these 
packages.