Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]
- Date: Tue, 8 May 2018 13:31:25 +0100
- From: Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]
Paul Gevers writes ("RFR: email about regressions [was: Dealing with ci.d.n for package regressions]"):
> Please find a proposed text for such an e-mail below. Comments or
> improvements very welcome.
Thanks. This looks broadly good but I wonder whether it would be
worth making it more explicit what the maintainers' next steps should
> To: $trigger@xxxxxxxxxxxxxxxxxxx, $broken@xxxxxxxxxxxxxxxxxxx
> CC: elbrus@xxxxxxxxxx
> Subject: New version of $trigger breaks autopkgtest of $broken in testing
> This e-mail is meant to trigger direct communication between the
> maintainers of the involved packages as one party has insight in what
> changed and the other party insight in what is being tested.
So I would insert here, before a paragraph break:
Please therefore get in touch with each other with your ideas about
what the causes of the problem might be, proposed patches, etc.
> After all,
(and delete this `After all').
> a regression in a reverse dependency can come due to one of the
> following reasons (of course not complete):
I think you need more information about process and authority, and
what to do if the maintainers disagree, or if one or the other does
not respond. We don't have a good formal mechanism for resolving
disagreements, and our NMU rules are restrictive and opaque, so this
is not so easy.
It can be appropriate to file an RC bug against the depended-on
package, if the regression amounts to an RC bug in the depending
package, and to keep it open while the matter is investigated. That
will prevent migration of an RC regression.
If the maintainers of the depending package don't have available
effort to fix a problem, it is appropriate for the maintainers of
the depended-on package to consider an NMU of the depending
package. Any such an NMU should take place in accordance with the
normal NMU rules.
Neither of the above steps should be seen as hostile; they are part
of trying to work together to keep Debian in tip-top shape.
If you find that you are not able to agree between you about the
right next steps, bug severities, etc., please try to find a neutral
third party to help you mediate and/or provide a third opinion.
Failing that your best bet is probably to post to debian-devel.