Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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

Some suggestions:

> =============================================================
> To: $trigger@packages.debian.org, $broken@packages.debian.org
> CC: elbrus@debian.org
> Subject: New version of $trigger breaks autopkgtest of $broken in testing
...
> This e-mail is meant to trigger direct communication between the

                          prompt

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

How about:

  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.

Ian.