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

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



Hi Chris,

[This question came up multiple times already in my e-mails about
regressions in autopkgtests.]

On 27-06-18 23:48, Chris Lamb wrote:
> (Paul, might make more sense to file bugs in future? Much easier to
> track and/or re-assign if necessary..)

I do that when I am *somewhat* confident which package should in
principal fix the regression. However, often I lack the time to dive
deeper and/or am unfamiliar with the packages involved and/or how the
autopkgtest in question works. To circumvent that problem, I send the
e-mails that we agreed upon on this list, albeit I don't due that
automatically even, because several packages have an extremely large
fall-out. This fall-out may be real (it appears to me that the current
python3-defaults may be an example of that as packages seem to be not
ready for Python3.7) or mostly just a matter of re-triggering tests as
the stack is highly in flux and should be considered together (like the
recent KDE stack update).

However, I can see the point and I prefer bugs personally as well. So
let's check what people here think of my proposal for guidance for
"by-standers" (I mean people like me that are not maintainer of either
the triggering package or one of the packages which autopkgtest regresses).

Proposal:
If one (me) can't determine the likely principle package that needs
fixing after some effort [1], one bug (per upload of the triggering
package) can be filed against the trigging package with the other
packages in X-Debbugs-CC and in Affects at normal severity. This bug can
contain similar text as we agreed upon earlier [2] (I'll write a
proposal if this idea is not rejected).

Paul
PS: any tips on how to handle the current python3-defaults situation is
highly appreciated.
https://qa.debian.org/excuses.php?package=python3-defaults

[1] Including, but not limited to, comparing the autopkgtest logs of the
passing and failing test, looking at patterns in the fall-out, examining
recent other regressions for the same failing autopkgtest, checking for
existing FTBFS or similar bugs.

[2] https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: