DMB knowledge base

Note

Page source

Sally’s note

This page should not go into the docs in its current format. Any knowledge that should be kept should find appropriate pages to live on (can be new pages).

I have only changed the formatting, corrected some minor spelling errors and updated links to point to internal references where the original wiki link points to a wiki page that has been moved already. The wording of the content is the same as the wiki page.

This page is intended to list all of the miscellaneous pieces of DMB knowledge that have accumulated over the years.

This page is authoritative. If you think you’ve found a mistake, please email the DMB.

Actions after a successful application

  1. Assign two meeting actions: one to make ACL changes, and one to announce the successful applicant. This is to make sure that the announcement does not get forgotten.

  2. Adjust ACLs

    1. (The part of this section moved to DMB Manage packagesets)

    2. (The part of this section moved to DMB Manage packagesets)

    3. Email technical-board@lists.ubuntu.com to inform them of the opened bug (include a link to the bug).

    4. Add the new TB bug to the DMB agenda in the “Open TB bugs” section.

    5. After the new packageset is created by the TB, a DMB member will need to add the appropriate packages.

  3. (This part of this section moved to DMB Manage packagesets)

  4. Announce successful applicants (this can be done in a single email or multiple emails as appropriate), as the Community Council would like to see these announced and we agreed in a subsequent meeting.

    Send emails to:

    • A reply to the original devel-permissions@lists.ubuntu.com thread (useful for future reference)

    • An email to ubuntu-devel@lists.ubuntu.com

    • An email to ubuntu-news-team@lists.ubuntu.com

  5. Remove the applicant’s agenda item if it is still present.

Actions after an unsuccessful application

Assign a meeting action to close the application. Closing an application involves:

  • Reply with regrets to the devel-permissions@lists.ubuntu.com thread only (useful for future reference when the applicant reapplies, and to make it clear that voting is complete).

  • Remove the applicant’s agenda item if it is still present.

out of context now

Delegating packageset uploader permissions

The DMB can decide to delegate the granting of upload rights to a packageset to a different group of developers. An example is that the Ubuntu Desktop team is self-managed. This means that applicants to that packageset do not come to the DMB, but they come to the team itself instead. The procedure is the same as for most other applications: somebody approaches the DMB with the proposal and it is voted on at the meeting. If approved, the body delegated should be added as an administrator of the team. It is very important that the teams come with a policy that says how applications will be managed. That is the document which you approve. You can see some examples on Developer Membership Board, and it is important that this list is kept current.

SRU Developers

Based on this thread, the DMB agreed to create a new team for SRU developers. This was announced to ubuntu-devel on 28 February 2017. See SRU Developers for details.

This team is for contributors who work mostly on SRUs but don’t necessarily yet have experience in wider Ubuntu development. Team membership allows the sponsors to get out of the way for SRUs only.

This team grants Ubuntu Membership. In other words, the DMB must determine that an applicant meets the requirements for Ubuntu Membership before granting an applicant membership of this team.

Add successful applicants to the ~ubuntu-sru-developers team.

Removals

There was some concern about potential bad uploads bothering the SRU team, so to mitigate this the DMB also agreed that individual ~ubuntu-sru-developers membership will be removed if any of:

  • ~ubuntu-sru resolves to remove the member (how they do so is up to them); or

  • The DMB resolves to remove the member by a quorate vote, and a vote will be held if any member of ~ubuntu-sru requests it.

Teams to add uploaders to

By default, uploaders to packagesets and per-package uploaders should be granted membership. This does not happen automatically – they must be added to the ~ubuntu-dev team. The reason for this is that occasionally the DMB may want to grant people upload rights if they do not meet the usual “significant and sustained” (interpreted as 6 months of contributions). That is: when adding a new packageset or PPU uploader, add the individual to ~ubuntu-dev if they are being granted membership or (for PPU only) to ~ubuntu-uploaders if they are not.

An exception to the above is that some packagesets require membership. You can identify these because the uploading teams are a member of ~ubuntu-dev instead of ~ubuntu-uploaders. In these cases applicants must satisfy the membership criteria: granting upload rights without membership is not possible.

This is, of course, only the case when adding uploaders. Memberships such as for Ubuntu Contributing Developers, which do not grant any upload rights to the Ubuntu Archive, do not require adding the new members to any of the above teams. Those should only be added to ~ubuntu-developer-members.

Accidental expiry

Since we usually require uploaders to self-renew after some period, sometimes this is missed by an uploader, and they request that we reinstate them shortly after expiry.

The DMB have long established that if it’s relatively soon after expiry in the judgement of an individual DMB member, then the uploader can have their membership reinstated without any further consideration.

If it has been some considerable time since the uploader’s team membership expired, then a full DMB vote is required as usual, but the DMB has in the past opted not to require a full application (just an agenda item and a quick discussion at the next meeting).

For the “relatively soon” case, the DMB member should use the following process:

  1. Make sure the request is available in the archives of devel-permissions@

  2. Go to the “Members” page on Launchpad for the team in question (e.g. ~ubuntu-core-dev members)

  3. Page to the end to locate the “Former members” section and locate the uploader.

  4. Check the “Expired on” date in the “Status” column is relatively recent. If it is not, then stop this process here and ask that the applicant attends a DMB meeting to request reinstatement as discussed above.

  5. Using the Edit button on the right of the former team member entry, change “Expiration” to “On” using the default date provided, write a suitable comment, and click the Renew button.

  6. Reply to the devel-permissions@ thread confirming renewal so there is a record in the Archive.