Re: git-ubuntu MP workflows in Launchpad
On Fri, Feb 16, 2024 at 03:33:26PM +, Robie Basak wrote: > Bryce mentioned the difficulty of removing the slot. Unfortunately > there's no UI for this, but I did confirm today that it can be done by > API. I wrote a quick script so that we can do it easily if needed: > https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/clear-review-slot.py Please submit this to ubuntu-dev-tools :-) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
On Wed, Aug 23, 2023 at 11:25:24AM +0100, Robie Basak wrote: > I also posted here yesterday, having forgotten about this thread: > https://discourse.ubuntu.com/t/improving-the-git-ubuntu-based-sponsorship-workflow/37964 Both of these threads died, and sorry again for accidentally splitting it. I've noticed some sponsorship entries getting lost due to the "grabbing" of review slots as I described, so I've gone ahead to implement ~ubuntu-sponsors-reporter. I've put a trivial MP up here: https://code.launchpad.net/~racb/ubuntu-sponsoring/+git/ubuntu-sponsoring/+merge/460697 Once that lands, I'll change the bot to use ~ubuntu-sponsors-reporter instead of ~ubuntu-sponsors. I don't think this will change anything in practice for anyone except to solve this grabbing problem. This new team is only for automation to use; nobody need use it directly or change what they're doing already in any way. Bryce mentioned the difficulty of removing the slot. Unfortunately there's no UI for this, but I did confirm today that it can be done by API. I wrote a quick script so that we can do it easily if needed: https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak/clear-review-slot.py Example of use: $ python3 clear-review-slot.py ubuntu-sponsors-reporter (for convenience, the URL is the one you see in your browser) I don't know who has permission to do this. Is it because I currently have some more permission over git-ubuntu repositories? Feedback appreciated. If it turns out that we need to give more people access to do this, perhaps we can arrange for a bot to watch for instructions in the MP or something similar. Robie signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
I also posted here yesterday, having forgotten about this thread: https://discourse.ubuntu.com/t/improving-the-git-ubuntu-based-sponsorship-workflow/37964 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
On Fri, Jun 30, 2023 at 10:03:56AM -0700, Steve Langasek wrote: > The one case where this is currently suboptimal is if the last comment on > the MP is from an Ubuntu dev saying it needs changes, but the submitter has > pushed new changes addressing that feedback without leaving a further > comment on the MP. An MP in such a state is ready for sponsorship team > action, but would have the commenter's name in bold and per the above would > be deprioritized. This could be addressed if the "last comment" field also > checked whether there were commits newer than the last comment. But I think > this is enough to be getting on with, even without that tweak. This is what I was alluding to when I said "imperfectly equivalent" :-) I did look into the Launchpad API to see if the commit timestamp was available without a full clone. Unfortunately it isn't. But there is a "date repository last updated" field, which might be good enough for now. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
On Thu, Jun 29, 2023 at 10:55:21PM +0100, Robie Basak wrote: > On Thu, Jun 29, 2023 at 02:36:06PM -0700, Steve Langasek wrote: > > I think the least-effort approach is for the handling of MPs for sponsorship > > to match the handling of bugs: ~ubuntu-sponsors is unsubscribed, and it's > > the responsibility of the submitter to re-subscribe them (and patch pilots > > have an obligation to make this clear with a comment). > It's worth noting that the sponsorship queue has a "person who last > commented" column that displays in bold if that person can upload the > package. For a first pass through the queue, one could ignore any row > where that column is bold. This is imperfectly equivalent to ignoring > MPs that are waiting on the contributor to take some action. That seems like it should work. It also looks like there are some bugs here, as http://reqorts.qa.ubuntu.com/reports/sponsoring/general.html currently displays juliank's name in italics instead of bold for lp:~enr0n/ubuntu/+source/triton:fix-lp2025279 which indicates "Ubuntu Developer, who can't upload the package in question" which of course is false? > Could it be used to address the fear of losing MPs, as well as the > desire not to waste every pilot's time on following up on MPs that are > actually waiting on the contributor? If it's not robust enough, what > could we do to help with that? The one case where this is currently suboptimal is if the last comment on the MP is from an Ubuntu dev saying it needs changes, but the submitter has pushed new changes addressing that feedback without leaving a further comment on the MP. An MP in such a state is ready for sponsorship team action, but would have the commenter's name in bold and per the above would be deprioritized. This could be addressed if the "last comment" field also checked whether there were commits newer than the last comment. But I think this is enough to be getting on with, even without that tweak. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
On Thu, Jun 29, 2023 at 02:36:06PM -0700, Steve Langasek wrote: > I think the least-effort approach is for the handling of MPs for sponsorship > to match the handling of bugs: ~ubuntu-sponsors is unsubscribed, and it's > the responsibility of the submitter to re-subscribe them (and patch pilots > have an obligation to make this clear with a comment). It's worth noting that the sponsorship queue has a "person who last commented" column that displays in bold if that person can upload the package. For a first pass through the queue, one could ignore any row where that column is bold. This is imperfectly equivalent to ignoring MPs that are waiting on the contributor to take some action. Could it be used to address the fear of losing MPs, as well as the desire not to waste every pilot's time on following up on MPs that are actually waiting on the contributor? If it's not robust enough, what could we do to help with that? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
On Thu, Jun 29, 2023 at 11:12:43AM -0700, Bryce Harrington wrote: > 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. This is my concern as well. An important part of patch piloting is identifying when a change is not ready for sponsorship, and sending it back to the submitter for revision. When this is done, it's on the submitter to re-submit it for sponsorship. If patch pilots have to track this, we are going to spend a lot of time polling MPs that are not ready for sponsorship. I think the least-effort approach is for the handling of MPs for sponsorship to match the handling of bugs: ~ubuntu-sponsors is unsubscribed, and it's the responsibility of the submitter to re-subscribe them (and patch pilots have an obligation to make this clear with a comment). A more clever approach would be to use a magic zero-member reviewer as Robie proposes, but to filter out any MPs from the sponsorship queue which have a negative review from a sponsor, and no further activity on the MP (either comments or commits) after that point. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
On Thu, Jun 29, 2023 at 09:13:01PM +0200, Sebastien Bacher wrote: > Hey Bryce, > > Le 29/06/2023 à 20:12, Bryce Harrington a écrit : > > 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. > > The fact that it matches the existing situation doesn't make it the right > outcome though... Oh 100% agreed there. Unsubscribing is a poor way to track state, and can be lossy in multiple ways, as you point out. But there is value in having similar processes work in consistent fashion. > In practice we often have bugs where the contributor did what was asked to > address the reviewers feedback but forgot to subscribe back the sponsors. > With the current workflow we have very little visibility on those cases and > they often end up lost in the launchpad noise. > > It would be nice if we had a way to at least query for those bugs so we > could review recent activity and see if there are cases were sponsors should > be subscribed back and hadn't... Yes, this is a good illustration of the point I made about there being essentially two different states needing tracked, with this describing the review state for the MP. In a bug-centric workflow, we would be able to set the bug to "Incomplete (without response)" which automatically gets set to "Incomplete (with response)" once there's a new comment on the bug. To the user the "reporter status" is just "Incomplete" in both cases, yet for the reviewer there are actually two substates - "with response" and "without response" - that can be queried for, so we can review recent activity and make adjustments to the visible state. Something equivalent to that but for Launchpad MP's would be very helpful, and would give us a better workflow than the one we have using subscription/unsubscription. Unfortunately, I'm not sure if this is doable with how Launchpad MPs work currently. Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
Hey Bryce, Le 29/06/2023 à 20:12, Bryce Harrington a écrit : 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. The fact that it matches the existing situation doesn't make it the right outcome though... In practice we often have bugs where the contributor did what was asked to address the reviewers feedback but forgot to subscribe back the sponsors. With the current workflow we have very little visibility on those cases and they often end up lost in the launchpad noise. It would be nice if we had a way to at least query for those bugs so we could review recent activity and see if there are cases were sponsors should be subscribed back and hadn't... Cheers, Sébastien -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: git-ubuntu MP workflows in Launchpad
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 pilo
git-ubuntu MP workflows in Launchpad
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 signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
