Application to form delegated team for sosreport

[Thomas Ward]

I will point out also from an actionable-policy perspective:

While the DMB is unstaffed thanks to Dan holding up the request for a 
new election to be run by the TB, **the DMB cannot action any requests 
for package permissions, packagesets, etc. until a new election happens 
and the DMB is restaffed**.

This is a problem that will break any packageset decisions and any 
current technical operations/policies.  As long as the DMB is unstaffed, 
decisions such as these on delegated packagesets, etc. cannot move 
forward without a TB vote since the TB is the only one capable of making 
these decisions when the DMB is unstaffed.  (Which is why the TB created 
and delegated membership rights decisions and such to the DMB)

The Technical Board and/or SABDFL should take a "Just Do It" approach 
and, despite any objections about the existing DMB vote, go forward with 
the election for DMB members.  Because, without a DMB, nothing will get 
done.  No new coredevs, no new SRU developers, no new contributing devs, 
no new MOTUs, etc.



Thomas

CC'd: Technical Board


On 5/16/22 10:27, Robie Basak wrote:
> 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.
>