On Thu, Jun 29, 2023 at 03:18:27PM +0100, Robie Basak wrote: > # 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.
The proposed solution of adding ~ubuntu-sponsor-reporter (either manually by the sponsoree or via some sort of automation) would indeed resolve this slot-stealing glitch in the workflow. I agree it's worked well for the server team and fits our workflow rather well. However, as you point out, this does create a secondary issue of making it harder to make things disappear from the sponsorship queue _intentionally_. For the server team workflow, the unclosable cruft seems to be a minor annoyance we just live with, but the volume we deal with is relatively small and we've got informal ways to connect our small number of internal reviewers and reviewees so the problem is not hard for us to work around. For the patch pilot workflow, the volume is higher and the number of reviewers broader, so I suspect a harder-to-make-things-disappear issue might present as much if not more pain than the slot-stealing glitch. > 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. I do love automation, however I think we shouldn't rule out letting this be somewhat manual. I.e. we already tell non-git-ubuntu sponsorees to manually sub ubuntu-sponsors: https://wiki.ubuntu.com/MOTU/Contributing "Set the bug to Status "Confirmed". Assign to "Nobody". Subscribe the ubuntu-sponsors team to add your bug to the Sponsorship Queue." So we could just have the docs direct them to add both ~ubuntu-sponsors *and* ~ubuntu-sponsors-reporter, and it wouldn't be inconsistent with established procedures. Obviously we want to avoid overwhelming new contributors with too many knobs, as that can lead to confusion and error, but adding reviewer slots is ameniable to documentation like we've done with the Ubuntu Maintainers' Handbook, and even scripted (ex. git-ubuntu's MP proposal filing functionality). One could argue also that having it be a manual knob has some edificational benefit since, as you also point out, as one gains experience one might seek reviews/approvals from specific teams instead of or in addition to patch pilot. Anyway, I'm all for automation but here I think we needn't rush into that, as IMHO doing it manually isn't too horrible and may have benefits. > 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). This is a very salient issue, and brings up a point I think warrants further attention and discussion. Indeed, I think this question of capturing a Pilot's evaluation is *the* most important point needing addressed. The status tracking for MPs provided by Launchpad is quite limited (for appropriate reasons), and the permissions to alter the state is quite restricted (also for appropriate reasons). So I don't see solutions easily at hand. But at least the needs are apparent. The way the Patch Pilot program is designed, the concept is for one pilot to handoff to the next once their shift is over, as opposed to an arrangement where, for example, a pilot would take ownership of a sponsorship request and shepherd it all the way from cradle to grave. Yes, many of us have been doing that anyway, and some might argue that's an overall better process, but it's not how the project has been formally defined to work. So, that means one pilot might identify some extra task for an MP, but then they'll de-shift, and a subsequent pilot evaluates if that task is done, and so on. This style of status wants to be tracked per-MP rather than per-reviewer, which goes against LP's MP workflow. A second obvious need is that there's really two separate statuses to track - one for the overall MP state from the submitter's perspective, and a second for the pilotability MP state, from the patch pilot program perspective. These two states are interrelated and one can probably be inferred from the other, but it's worth recognizing that notionally they're conceptually distinct. For example, a not at all uncommon case is an MP for a change in Ubuntu that instead needs to be sent to Debian or upstream. From a patch pilot POV we evaluate and decide that needs done, and then we want to close it out since no further piloting work will be needed. However, from the reporters' POV this seems like just a picky detail, and getting their MP marked as rejected might seem unfriendly or like buck-passing, neither of which are our actual intent. However, we currently have no way to track these two states independently so we've got a bit of friction. Anyway, I wish I had solutions to propose. Maybe it's something we just have to continue to just live with. But I do think it'd be valuable to discuss further, as it seems like any improvements could have good payoff. > 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. I'd argue this is the same workflow situation with non-git-ubuntu bug-based sponsorship requests. There the sponsor can unsubscribe ~ubuntu-sponsors and the sponsoree is either told or knows via documentation to re-add ~ubuntu-sponsors when they've resolved things and need pilot attention once more. There's some downsides to this process of things falling through the cracks, so I can't say I'm an absolute fan of it, but it's an already established practice here and in some other similar workflows, so at least we'd be consistent. Bryce > # 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBCgAGBQJknZKzAAoJEOVkucJ1vdUu1zYQALLw7XY9D3qvQDt0G0W+dn6n > m2elmTM3XXdeTRV9o9EUFUQbm/IBfISPKrsKiAh74tX3Fl0PxkhYV0cMtyu3RJgk > 6XKgeGdm4bb4R6DQ1goEp5Prgt1ecXsFRsc8kdfzI4t52KpChS4VA948NgBkDUZB > vvum1j/S6qSnGbLFO+wetiRsCtrL6mgUNx0aKF/m/nQcyiS/DhhazyWCXN8CM+iw > GYXvTNflcG2KWLlFrYb2c9REhdGAoKTlnMWOhdR0vX9fIu6tkb5ZyKL9FhE9ARxf > 8BiyRGOOr4QGaR2VYCi+4EjXUH+7QWmizZegJbzRaPE11uIGFtlXDgq0HrItWS0y > JdAgCz+PI67YF1zTvOCDsnhyFT4OoXZFyhb7vPvdhnMoI3R7h+bYmGTFuH/1gRoy > lPXuUcsDAXlVi4Vh4UiXIraSiAVescQCxz4RG97FzmeQpflHhrXvQ4U3Dh3PAcLh > VGwcHEqdBv1zS+SSkE+xn8p9t/41YK70VguR9G7+vea4uksLmw3meQ6nfrVUiL4B > GjI6Me1+g3drmN0JzaFbVFz1mye40uPnOJj6y6NZJ95LG/uYGX72hxLk96g4J9OS > zZnJSXv6QPBoExnjRexbwzM8ZgRNGdefv8IhTJm7IvvzSwqdvOxgS4JXNFqB7zCE > 85sep8tC4vWAma0XnYdT > =F3Bq > -----END PGP SIGNATURE----- > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
