Application to form delegated team for sosreport

[Robie Basak]

The code of conduct says:

"The poorest decision of all is no decision: clarity of direction has
value in itself. Sometimes all the data are not available, or consensus
is elusive. A decision must still be made. There is no guarantee of a
perfect decision every time - we prefer to err, learn, and err less in
future than to postpone action indefinitely."

The next scheduled DMB meeting is in less than one hour. So I'm going to
put on my TB hat and call it.

I am hereby extending the terms of the expired DMB members for two
months, starting today. I will proceed with running the DMB election as
soon as I can. As soon as the election results are announced, the
extension will end, and the newly elected members will take their place.

I understand this action to be supported by at least two other TB
members and one CC member anyway, so I trust that this is the
appropriate thing to do.

Robie

On Mon, May 16, 2022 at 01:27:20PM -0400, Thomas Ward wrote:
> 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.
> >
> 
> 
-------------- 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/1d68779a/attachment-0001.sig>