[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug filing for autopkgtest regressions? [Was: Re: appears to break multiple autopkgtests]



On 06/29/2018 01:41 AM, Ian Jackson wrote:
> 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 ?

I don't have the energy to care about packages outside of my control.

R people should take care of these packages by noticing regressions in
their packages.

>>> 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.

This. And don't shift the burden to the maintainer of a package which
just happened to trigger autopkgtests, the maintainers of the package
whose tests fail are primarily responsible.

>> 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).

Kind Regards,

Bas


Reply to: