SRUs solely for dep8 updates

[Lukasz Zemczak]

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 <steve.langasek at ubuntu.com> 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/
> slangasek at ubuntu.com                                     vorlon at debian.org
>
> --
> Ubuntu-release mailing list
> Ubuntu-release at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
>



-- 
Łukasz 'sil2100' Zemczak
 Foundations Team
 lukasz.zemczak at canonical.com
 www.canonical.com