SRU bug subscription for sponsors

[Robie Basak]

On Thu, Jun 01, 2023 at 09:51:22PM +0200, Sebastien Bacher wrote:
> Hey Robie,
> 
> While I understand the rational, that's putting the annoyance on the
> sponsors and might decrease their motivation to help with the uploads. The
> annoyance being that by helping reviewing/uploading some change we will now
> end up being email nagged for every action/user follow up on the issues
> until you manual go to launchpad to unsubscribe.
> 
> Did the SRU team consider trying to identify the situations where the
> sponsors actual need to be subscribed and try to add them back only in those
> cases? Or to encourage the sponsoree to reach out to the sponsor again if
> needed? Or to have the SRU team subscribe back the sponsor only in case
> where an action is actually needed?

It's really difficult to determine the sponsor of an upload before it
has been accepted. This is LP: #1898861. My script implements a rather
convoluted workaround but this isn't really practical to do at SRU
review time. I'm happy to discuss alternative approaches, but whatever
we do needs to be quick, practical and effective.

I have always made the assumption that it is an understood expectation
that sponsors will follow through on uploads until they land. For the
development release that would include proposed migration (after that
was introduced). For SRUs, this includes SRU verification, resolving
failed autopkgtests, answering SRU team questions and so on.

People who are being sponsored cannot be expected to fully understand
the process - that's the point of sponsorship, right?

So leaving them to their own devices after an upload doesn't make sense
to me. They often don't manage to perform SRU verification to an
acceptable standard, or know to look at the pending-sru report to clear
any FTBFS or autopkgtest failures, make sure all relevant bugs are
verified, and so on.

On my SRU shift day, I'm often flooded with pings from multiple
directions (internal Canonical Mattermost, both in a team channel and in
private messages, public IRC, private IRC messages and so on). Many of
these enquiries seem to be from non-uploaders who were sponsored and now
don't know what to do. My replies might be of the type "no X can't be
released because bug Y is not verified".

Elsewhere we're talking about SRU team workload. Helping non-uploaders
learn and conform to already established process and policy strikes me
as something that doesn't need SRU team members' time. Surely that's
what sponsors are for? I don't mind fielding questions directly for
those who know what they're asking, but when non-uploaders being
sponsored don't know the process, surely it's a more efficient use of
time to have their sponsor help them with those, and let the SRU team
spend their time making the decisions that actually require their
privilege? This is one of the factors that I think unnecessarily
consumes SRU members' time, and I thought auto-subscribing sponsors
would be an easy and obvious fix!

Note that this is not just about explicit SRU team queries. If sponsors
just "drive-by" and don't get involved, then you end up with SRUs
"stuck" that never land, and so all the effort getting to that point was
wasted. See the pending-sru report for the SRUs are languishing awaiting
verification, for example.

Therefore, I propose that it should be a *hard requirement* for sponsors
to ensure that they follow through anything they sponsor until the
upload lands. This includes fielding enquiries from any direction, and
therefore this means subscribing to the relevant bugs.

I had thought this was already understood to be the case, and so my
auto-subscription script would be the obviously correct thing to do and
not result in any complaints.

If sponsors aren't prepared to do this, I question whether what they are
doing is actually useful. The harm is that they are leaving
non-uploaders in the cold, and review teams are spending unnecessary
effort that could be diverted to doing the reviews that only they can
do.

Robie
-------------- 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/20230614/8f5caaa2/attachment.sig>