Usually, whenever I see an SRU that only attempts to fix an autopkgtest regression, I first check how frequently the given package receives regular updates. If I see the package is really 'popular' and gets a lot of love for the stable series, I reach out to the uploader for him/her to consider bundling the change in the nearest bigger SRU. But for most packages I just accept those changes as they are, since there is no guarantee when the nearest regular SRU will be prepared.
My general take on autopkgtest-fix-only SRUs can be summarized with: "it's not that big of a deal". In the common case, accepting and then handling of the SRU does not waste enough of my time and resources for me to consider bouncing it back. The verification of such bugs is also very easy, so those have a potential of not lingering in -proposed for too long. Uploads are cheap, IMO. And since such uploads potentially do make things easier for both me, as an SRU member, and the developer, that's usually a green light for me. Autopkgtest regressions frequently cause uploads to get blocked for longer periods of time, usually with us waiting for the uploader to assess if it's a regression or not, with ubuntu-sru having to sometimes 'remind' people in the comments about those as well. The faster an autopkgtest regression is fixed, the better for both sides. Of course this all depends on the actual change - if the change does not only affect code of the test, the situation is different. As always it's a case-by-case situation. If the concern here is related to the fact that such uploads can block other, real bugfix uploads before the autopkgtest fix gets released into -updates, I don't think that's much of a problem. When dealing with autopkgtest fixes that get 'blocked' in -proposed without verification for too long, I generally wouldn't mind someone to upload an upload 'on top' of that version (if the changes are preserved with a -v during source build) and proceeding. The only verification required is anyway checking if the failure is indeed fixed or not. We could also think of maybe some 'fast-track' rule for such uploads, but on the other hand I guess it's really not worth complicating our rules. Here again my earlier summary shows: "it's not that big of a deal". That's my humble POV. Cheers, On 24 March 2018 at 01:48, Steve Langasek <[email protected]> wrote: > On Thu, Mar 22, 2018 at 10:04:11AM +0000, Robie Basak wrote: >> > > I've always been reluctant to accept SRUs for things that are not user >> > > impacting. > >> > > For consistency, please could we decide a policy on this? > >> > To understand, are you looking for consistency because you think the policy >> > should be to reject autopkgtest-only fixes and you don't want uploaders to >> > shop their upload around to multiple SRU team members to get the answer >> > they >> > want? Or is it that you think it's unfair to uploaders and a waste of >> > their >> > time to have done work that might then be rejected? Or some other reason? > >> I think consistency saves wasting everyone's time, so all of the above. >> Uploaders would know what to expect and SRU team mebmers won't duplicate >> review time. It would a waste for me to reject or defer an SRU and for >> another SRU team member to later accept it, and frustrating for >> uploaders to be playing a lottery like that. > > I agree that this would be wasteful. I'm not sure it comes up often enough > that we would be saving energy by attempting to (agree on and) adopt a hard > policy, however. > > My own view is that for the specific narrow case of a package whose > autopkgtests have regressed post-release, and there are dependencies of that > package being SRUed, and there is an Ubuntu developer who cares enough about > the regressed package to prepare an upload a fix, it is reasonable to accept > an SRU for this. > > I'm interested to hear the opinion of other members of the SRU team as well. > > -- > 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 http://www.debian.org/ > [email protected] [email protected] > > -- > Ubuntu-release mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release > -- Łukasz 'sil2100' Zemczak Foundations Team [email protected] www.canonical.com -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
