> # 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
