Re: SRU bug subscription for sponsors
Hi, On Thu, Jun 15, 2023 at 6:50 AM Sebastien Bacher wrote: > > Le 14/06/2023 à 22:32, Robie Basak a écrit : > > > > 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. > > The issue is not really 'to be prepared to do this'. I do agree with you Good ;) > that the sponsors should be engaged in the process, especially when > sponsoring work from someone who isn't familiar with all the details of It's not just familiarity. Sometimes the person just doesn't have enough privileges to take an action, like nominate a series, or retry autopkgtests. Specially retry autopkgtests. > the system. It is especially true for SRU uploads which often need > follow-ups to deal with the issues you mentioned. Subscribing to the > corresponding launchpad bug makes sense in that context and that's > something I would recommend doing. I agree. > > Where I disagree is that it should be forced on us this way, without > even letting us the change to have a public discussion here before > having the change in action. Well, the discussion is happening now. > A few concerns I have > > 1. I've noticed that people (even in our teams at Canonical) don't keep > up with bug emails and some end up just ignoring anything coming from > launchpad. The issue isn't new and isn't due to the new bot, but the bot > is adding to the problem. gmail is super bad at filtering email, agreed. What other way would we have to follow the progress of an upload that was sponsored? Who is in the best position to do that? > 2. You argue that we should expect that the people asking for sponsoring > aren't familiar with the processes or they wouldn't ask for sponsoring > such they need guidance and involvement from their sponsors. While > that's true for a class of contributors it's often not the case. I'm > regularly sponsoring work for people in my team who are perfectly able > to follow up on their changes and know the process, it just happens that > sometime they need to upload a fix outside of the packagesets they have > access to Or retry an autopkgtest with triggers or special options. Besides the question of ACLs, where most sponsored people wouldn't even be able to do it, there is a tricky learning curve to deal with autopkgtest and migration issues. So much that it's a standard recurring question when someone applies for core dev privileges. > > 3. You say "sponsors will follow through on uploads until they land", > could the script be made to be smart enough to unsubscribe the sponsor Maybe, but once a bug is "fix released" (since the fix landed), there normally aren't many follow-ups to it. If there are, then it might have introduced a regression, in which case you would definitely want to know about it, or it's another type of comment and you can easily unsubscribe from the bug then. > at that point? Launchpad bugs are often noisy (users sometime comment on > unrelated closed issues which seem similar to what they face, they ask > for guidance on how to install an SRU updates, ...) which adds to > problem 1. Yes I can go to unsubscribe manually if I'm bothered enough > but that's just one more annoyance and manual action needed which > contributes to the 'it's easier to just filter launchpad emails in a > folder and ignore those'. Imagine the annoyance of the SRU team when they find a bug that was supposedly verified, tags flipped, but the package didn't even build (it's an FTBFS) :) Somebody must have gotten an email about it. Could that email be one of those that are being ignored? Or when somebody asks why the sru hasn't landed yet, and it has current autopkgtest failures that the sponsored person cannot do anything about other than ask for help somewhere, perhaps in the bug. Would that be lost too in some folder? I do believe sponsoring is more than pressing a button and forgetting about it. And I wonder how it's working in the new patch pilot program, if uploads are being followed through, or being forgotten after dput (my shift will be in a few days). -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SRU bug subscription for sponsors
Le 14/06/2023 à 22:32, Robie Basak a écrit : 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. The issue is not really 'to be prepared to do this'. I do agree with you that the sponsors should be engaged in the process, especially when sponsoring work from someone who isn't familiar with all the details of the system. It is especially true for SRU uploads which often need follow-ups to deal with the issues you mentioned. Subscribing to the corresponding launchpad bug makes sense in that context and that's something I would recommend doing. Where I disagree is that it should be forced on us this way, without even letting us the change to have a public discussion here before having the change in action. A few concerns I have 1. I've noticed that people (even in our teams at Canonical) don't keep up with bug emails and some end up just ignoring anything coming from launchpad. The issue isn't new and isn't due to the new bot, but the bot is adding to the problem. 2. You argue that we should expect that the people asking for sponsoring aren't familiar with the processes or they wouldn't ask for sponsoring such they need guidance and involvement from their sponsors. While that's true for a class of contributors it's often not the case. I'm regularly sponsoring work for people in my team who are perfectly able to follow up on their changes and know the process, it just happens that sometime they need to upload a fix outside of the packagesets they have access to 3. You say "sponsors will follow through on uploads until they land", could the script be made to be smart enough to unsubscribe the sponsor at that point? Launchpad bugs are often noisy (users sometime comment on unrelated closed issues which seem similar to what they face, they ask for guidance on how to install an SRU updates, ...) which adds to problem 1. Yes I can go to unsubscribe manually if I'm bothered enough but that's just one more annoyance and manual action needed which contributes to the 'it's easier to just filter launchpad emails in a folder and ignore those'. 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: SRU bug subscription for sponsors
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 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: SRU bug subscription for sponsors
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? Cheers, Sébastien Bacher Le 01/06/2023 à 18:59, Robie Basak a écrit : Dear Ubuntu Developers, If you sponsor an SRU, please subscribe to its bugs so that you can respond to any enquiries from the SRU team, and step in as necessary. We're now also subscribing SRU sponsors automatically, but the initial implementation is racy, so this might not always occur if SRU unapproved processing is too quick (ha!). Hopefully it'll help in most cases, so this should be much better than nothing. Incremental improvements! We find that sometimes the sponsoree doesn't understand the process, which is of course to be expected - that's what the sponsorship process is for! But it seemed that sometimes sponsors weren't getting the message, and the SRU would stall - hence this request, and the autosubscription to help. Robie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
SRU bug subscription for sponsors
Dear Ubuntu Developers, If you sponsor an SRU, please subscribe to its bugs so that you can respond to any enquiries from the SRU team, and step in as necessary. We're now also subscribing SRU sponsors automatically, but the initial implementation is racy, so this might not always occur if SRU unapproved processing is too quick (ha!). Hopefully it'll help in most cases, so this should be much better than nothing. Incremental improvements! We find that sometimes the sponsoree doesn't understand the process, which is of course to be expected - that's what the sponsorship process is for! But it seemed that sometimes sponsors weren't getting the message, and the SRU would stall - hence this request, and the autosubscription to help. 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
