Re: Bug filing for autopkgtest regressions? [Was: Re: appears to break multiple autopkgtests]
Paul Gevers writes ("Re: Bug filing for autopkgtest regressions? [Was: Re: appears to break multiple autopkgtests]"):
> On 28-06-18 20:50, Sebastiaan Couwenberg wrote:
> > Please don't file bugs until the triggering package is a single package.
> > Case in point, the upload of gdal (2.3.1+dfsg-1) triggered the
> > autopkgtest of r-cran-mi/1.0-6 which failed because r-base-core was also
> > updated to 3.5.0-5. The latter is the actual cause of the regression,
> > not gdal which triggered the autopkgtest. I would be annoyed if a bug
> > was filed against gdal in this case, and having to reassign it.
I find this response perplexing (although I confess I don't quite
follow all the package relationships here, nor the bug referred to).
Sebastian, are you not more worried about the possibility that
r-base-core would migrate, causing lossage, than that you would
receive a bug mail requiring a simple BTS control action to reassign ?
> > How will you deal with cases such as these other packages than the
> > trigger are the cause?
>
> This is exactly the response why I haven't done this before. I can't
> deal with that (apart from the investment of "some effort").
Quite. In the general case it is not easy to determine the cause.
People in charge of CI systems should not be expected to do that kind
of investigation. Ideally they would be expected not to do any triage
at all. That task needs to be distributed amongst the whole project.
CI failure triage and investigation needs to be done by the
maintainer(s) of involved package(s), who probably have some idea (or
some way to guess or find out) what on earth is going on.
> So there is exactly this risk. On the other hand, the risk is that a
> (severe, who knows?) regression migrates because no bug is filed. I
> agree with Chris' response and I think most maintainers would rather
> want it and reassign, than not getting it. How to judge if
> Sebastiaans response is that of the minority or the majority? (And
> what does that mean for the outcome anyways?)
If we cannot resolve this some other way we have, really, three ways
to decide:
1. You just go ahead.
2. You ask the DPL or owneer@bugs or the TC or someone for a formal
decision. Then, if the DPL or the TC say to go ahead, you add
something to your emails along the lines of "This message was sent
after consultation with { whoever }. if you think that { mails of
this kind should not be sent | bugs of this kind should not be
filed }, please take it up with { owner@bugs | DPL TC }.
3. You do not send the mails.
Note that not making a decison is equivalent to (3).
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: