SRUs solely for dep8 updates
Steve Langasek
steve.langasek at ubuntu.com
Tue Mar 27 06:46:20 UTC 2018
Hi Ćukasz,
Thanks for weighing in.
One point that I think Robie has in mind when objecting to an
autopkgtest-only SRU, and that it doesn't seem to me is addressed in your
mail, is that every additional SRU carries costs for the user: some concrete
(every SRU increases the amount that the user has to download), and some
merely statistical (our SRU verification process is imperfect, and every SRU
carries with it some risk of introducing regressions - including due to
miscompilations of unchanged code, or tickling existing bugs in package
maintainer scripts).
Do you specifically think that these costs are outweighed by the benefits of
an autopkgtest-only SRU?
On Mon, Mar 26, 2018 at 09:43:00AM +0200, Lukasz Zemczak wrote:
> 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.
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20180326/c4b0d64d/attachment.sig>
More information about the Ubuntu-release
mailing list