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
