Re: Bug filing for autopkgtest regressions? [Was: Re: appears to break multiple autopkgtests]
Sebastiaan Couwenberg writes ("Re: Bug filing for autopkgtest regressions? [Was: Re: appears to break multiple autopkgtests]"):
> On 06/29/2018 01:41 AM, Ian Jackson wrote:
> > 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.
Your response clarifies (implicitly) some things for me.
> > 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.
I was confused by Paul's earlier mail. I think that it is probably
best if bugs are filed in the first instance against the package whose
autopkgtests fail (ie not the triggering package).
The maintainer of that package has an obvious interest in keeping
their dependency stack healthy, and is so much less likely to find
this a nuisance.
Sebastiaan's response shows that doing it the other way around can
involve people in having to deal with lossage in their dependencies,
which they may not know anything about or be able to do anything
about.
Ian.
Reply to: