Application to form delegated team for sosreport

[Robie Basak]

On Wed, Mar 30, 2022 at 06:34:58AM -0400, Dan Streetman wrote:
> I am applying for creation of a delegated team for upload access of
> (initially) the sosreport package.
> 
> The suggested name for the packageset is 'ubuntu-support', and
> criteria for package membership in the packageset is packages used for
> debugging and supporting Ubuntu.
> 
> The set of packages, initially, is only the sosreport package, though
> it is likely we will apply to add more packages in the future.
> 
> The initial list of members is only me, ddstreet, though after team
> creation individual members will apply to join.

To clarify, I understand that what Dan is requesting to be a new
packageset, defined as "packages used for debugging and supporting
Ubuntu", to what a new ~ubuntu-support-uploaders LP team would be able
to upload. The team would be owned and membership managed by the DMB,
and membership of the team (to be able to upload to the packageset)
would require an application to the DMB under the usual process.

Dan belonging to the team would be a no-op since he's already a core
dev. Therefore I don't see the point in him being in this team from an
ACL perspective. I also don't think there'd be any difference from a DMB
process perspective if Dan were a member or not. It might be useful from
a social perspective though, so I have no objection to that part.

However, for there to be a useful point in having this packageset and
uploading team, we need an actual applicant who can't already upload
sosreport. And for there to be any point in this being a packageset over
a simple PPU for sosreport, we'd need a second applicant or a second
package.

I suggest there's only any point in proceeding once we have either a
second applicant and a second package to add to the packageset. When
there's a first applicant, we can simply grant PPU. We can convert it to
a packageset when there's an actual need.

***
The key thing is that we grant uploaders what they need to unblock them.
***

It's our job to make sure that a qualified uploaders gets an ACL "+1"
when they upload what we agree they should be able to upload. Whether
this is through PPU or a packageset is really just about administrative
convenience for us.

Separately, a description of "packages used for debugging and supporting
Ubuntu" would seem to include gdb for example. I think gdb should be
reserved for core devs and isn't appropriate for a packageset. So if we
do go ahead and create a packageset, I think the proposed packageset
description needs adjusting first. This is important because under our
current documented process
(https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Packagesets)
any one DMB member can add a package to a packageset on request,
verifying that it meets the description only, without any further
consultation required. Working out what would be a good description to
use would be far easier when we actually have a known set of packages to
work with. For now, I therefore suggest that it's just "sosreport" and
this is best expressed using PPU.

This also prevents a proliferation of unnecessary packagesets. Only the
PPUs that actually grow in practice to need packagesets need become
packagesets. This saves a bunch of unnecessary admin.

Or, if you think that PPUs are more difficult, perhaps we should abolish
PPUs and make everything a packageset? I don't think it makes sense for
PPU to exist as a concept if we're not going to use it.

My conclusion: there's no need to do this right now. If new contributors
want to apply to be able to upload sosreport, please just request PPU
for sosreport. If we get multiple contributors and multiple packages
that fit a category, then we would just convert existing PPU to
sosreport as part of those future applications.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20220516/bdaa1941/attachment.sig>