Ordering of decisions to create a packageset and a first uploader

[Robie Basak]

There seems to have been quite some confusion in recent meetings about
creating a packageset and a first uploader. I feel that we've spent too
much time in meetings on this. I'd like to reach consensus here and have
this thread to refer to so that we're more easily able to JFDI during
meetings.

I think the point the current DMB has yet to settle is how to define a
packageset and consider an application for a first uploader to that
packageset at the same time. This seems to waste a ton of time in
meetings, so it'd be nice to have an agreement on how we all expect this
to work so that we can just get on with it at meetings rather than
debate process.

So here's my opinion. Let me start with some points I think are
uncontroversial:

 1. Packagesets have formal definitions. For example, from
 http://people.canonical.com/~ubuntu-archive/packagesets/zesty/ the
 definition of the "ubuntu-mate" packageset is "Ubuntu MATE" and the
 definition of the "qt5" packageset is "Packages for source developed by
 http://qt-project.org/".

 2. The DMB decides on a packageset definition (or a change to an
 existing packageset definition) by majority vote. This must happen
 before a new packageset can be created.

 3. Any single DMB member can decide on requests to add or remove
 packages from a packageset by considering the request against the
 existing definition. Effectively we (as the board) delegate this
 decision to specific individuals.

Now my argument:

 4. We could define a packageset without uploaders. To do this we'd need
 only to agree on a definition formally by majority vote.

 5. If we also decided to agree on the initial set of packages formally
 by majority vote, we could.

 6. But that (point 5) would be moot because any one DMB member could
 change the set the following day based on the definition, due to point
 3 above. Of course we want to work together so we shouldn't
 deliberately act against each other without getting consensus first.
 But the point remains: due to 3, by approving an applicant we're
 agreeing uploads to the packageset *including all future changes to
 that packageset* and those changes would happen informally and without
 quorum.

 7. Due to 6, it makes little sense to *formally* require 5 to happen
 before considering the application of the first applicant.

 8. We do of course want to have general agreement on edge cases in
 order to make point 3 work. To do that, I expect we will discuss
 anything as needed either before or after the vote anyway. My argument
 here is just that it is pointless having a formal vote on it, because
 doing so would be moot because of the delgation to individual members
 in point 3.

 9. In order to efficiently arrive at a packageset definition that works
 for both the applicant and the DMB, I expect that the applicant would
 propose an initial package list in the corresponding application wiki
 page. The DMB would then consider this and work with the application to
 arrive at a proposed packageset definition before the formal vote on
 the application.

My conclusion:

Discussions about what packages a given packageset definition includes
can happen before or after the vote (and in fact at any time), but I
expect this to be informal and not require a vote because we rely on
individual member delegation to maintain the set anyway.

Therefore, the normal way we'd expect an application for a first
uploader to a new packageset to go is:

 1. Applicant applies with the proposed initial list of packages and
 optionally a proposed definition in the application itself.

 2. Any informal discussion as required at the meeting, perhaps to
 arrive at a packageset definition that works for both the DMB and the
 applicant, and perhaps to further get informal agreement across the DMB
 on how edge cases work with that definition.

 3. A formal vote at the meeting in the form:

    #vote Grant <applicant> upload access to a new packageset defined as <description>

Opinions?

Robie
-------------- 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/20170404/5d2a6ccb/attachment.pgp>