git-ubuntu MP workflows in Launchpad

[Robie Basak]

Dear Ubuntu Developers,

Currently it's unclear what patch pilots are supposed to do when an MP
in the sponsorship queue cannot be resolved immediately. This relates to
how the sponsorship queue behaves as MP state changes. It seems that we
should have a "manual for sponsors" that explains what to do under
various cirumstances, but we can't write that yet because we haven't
figured out how the various workflows should interact with Launchpad
functionality.

In this thread I'd like to discuss and conclude how this should work.

# The "grabbing" of review slots

This is the immediate problem.

The sponsorship queue displays git-ubuntu MPs for which ~ubuntu-sponsors
has a review slot. But if a member of the team votes (eg. "Needs
Information"), then Launchpad replaces the review slot reviewer with
that individual. Then ~ubuntu-sponsors is no longer a reviewer, so the
MP disappears from the sponsorship queue, never to reappear unless
someone adds an ~ubuntu-sponsors slot manually.

# General requirements

Teams use git-ubuntu MPs who do not require general sponsorship. For
example, the Canonical Server Team has a peer review policy, so we
submit MPs for review even when the proposer can upload the package.
These MPs should not appear in the sponsorship queue. Similarly, I
imagine an experienced Ubuntu developer submitting an MP against a
git-ubuntu branch for which they want review from a specific team, and
will add a review slot just for that team. I think these MPs should be
left alone by other more general workflows.

It needs to be possible for a git-ubuntu MP to end up in the sponsoring
queue. This should happen automatically for contributors who won't be
aware of any process that we decide, but do manage to figure out how to
submit the MP against a git-ubuntu branch.

When patch piloting, a sponsor may need to leave a vote on an MP such as
"Needs Fixing". Once the contributor has fixed the MP, we need to ensure
that MP is on the sponsorship queue (whether or not it was temporarily
removed).

It's possible that sponsors will want to temporarily remove an MP from
the sponsorship queue until the contributor responds to feedback. But
there is a risk that a contributor won't know what to do (or fail to
follow instructions) so the MP will get lost, so whether or not this
should be part of the general sponsoring/patch piloting workflow is up
for discussion.

# Current behaviour

The sponsorship queue displays MPs only if ~ubuntu-sponsors is a
reviewer. To try to meet the requirements above, my bot[1] adds
~ubuntu-sponsors as a reviewer only if the proposer cannot upload the
package and the only existing review requests are for the teams that
often appear but we do not care about (~git-ubuntu-iport etc).

# How we fixed this on the server team

I created a team called ~canonical-server-reporter that deliberately has
zero members. We add this team as a reviewer to our MPs to flag it for
inclusion in our reports and bot behaviour, but the team never votes
(since it has no members). This way the review slot is never "grabbed",
making it more of a mechanism to "tag" an MP than for actual review
purposes.

# Other problems that already have a planned solution

Currently sponsors aren't able to set git-ubuntu MP states such as
Rejected or Merged. This is known[2] and should be fixed once we have
staging branches[3] and MPs are filed against those.

In the meantime, I'm changing MP state manually in response to pings,
and if that gets too much I'll write a stop-gap bot to operate until the
staged branch functionality lands.

# Where to go from here?

Our final solution will need to accommodate workflows of all git-ubuntu
users, which basically means all Ubuntu developers and contributors.

Do other teams have workflow requirements I've not listed above? Is
there anything we need to ensure we support that I've missed?

Would creating a ~ubuntu-sponsor-reporter team used the same way as
~canonical-server-reporter be sufficient, changing the bot and report to
use that team instead?

Is there a better way to fit Launchpad MPs into our workflow
requirements?

Thanks,

Robie

[1] https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/lp_auto_sponsor.py
[2] https://launchpad.net/bugs/2007731
[3] https://discourse.ubuntu.com/t/spec-git-ubuntu-staged-uploads/35409
-------------- 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/ubuntu-devel/attachments/20230629/7e837fb6/attachment.sig>