[pkg-go] golang-github-prometheus-common/0+git20180413.d0f7cd6-1 appears to break golang-github-prometheus-client-golang/0.8.0-2 autopkgtest in testing

[Paul Gevers]

Dear maintainers,

[This e-mail is automatically sent. V3.2 (20180518)]

tl;dr: golang-github-prometheus-common/0+git20180413.d0f7cd6-1 appears to break golang-github-prometheus-client-golang/0.8.0-2 autopkgtest in testing
see: https://ci.debian.net/packages/g/golang-github-prometheus-client-golang/testing/amd64/
and https://qa.debian.org/excuses.php?package=golang-github-prometheus-common

As recently announced [1] Debian is now running autopkgtests in testing
to check if the migration of a new source package causes regressions. It
does this with the binary packages of the new version of the source
package from unstable.

With a recent upload of golang-github-prometheus-common the autopkgtest of golang-github-prometheus-client-golang
started to fail in testing [2]. This is currently delaying the migration
of golang-github-prometheus-common version 0+git20180413.d0f7cd6-1 [3].

This e-mail is meant to trigger prompt 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. Please
therefore get in touch with each other with your ideas about what the
causes of the problem might be, proposed patches, etc. A regression in a
reverse dependency can be due to one of the following reasons (of course
not complete):
* new bug in the candidate package (fix the package)
* bug in the test case that only gets triggered due to the update (fix
  the reverse dependency, but see below)
* out-of-date reference date in the test case that captures a former bug
  in the candidate package (fix the reverse dependency, but see below)
* deprecation of functionality that is used in the reverse dependency
  and/or its test case (discussion needed)
* regression due to other packages from unstable that are installed to 
  fulfill (versioned) Depends (contact maintainers of those).
Triaging tips are being collected on the Debian Wiki [4].

Unfortunately sometimes a regression is only intermittent. Ideally this
should be fixed, but it may be OK to just have the autopkgtest retried
(a link is available in the excuses [3]).

There are cases where it is required to have multiple packages migrate
together to have the test cases pass, e.g. when there was a bug in a
regressing test case of a reverse dependency and that got fixed. In that
case the test cases need to be triggered with both packages from
unstable (reply to this e-mail and/or contact the ci-team [5]) or just
wait until the aging time is over (if the fixed reverse dependency
migrates before that time, the failed test can be retriggered [3]).

Of course no system is perfect. In case a framework issue is suspected,
don't hesitate to raise the issue via BTS or to the ci-team [5] (reply to
me is also fine for initial cross-check).

To avoid stepping on peoples toes, this e-mail does not automatically
generate a bug in the BTS, but it is highly recommended to forward this
e-mail there (psuedo-header boilerplate below [6,7]) in case it is
clear which package should solve this regression.

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.

[1] https://lists.debian.org/debian-devel-announce/2018/05/msg00001.html
[2] https://ci.debian.net/packages/g/golang-github-prometheus-client-golang/testing/amd64/
[3] https://qa.debian.org/excuses.php?package=golang-github-prometheus-common
[4] https://wiki.debian.org/ContinuousIntegration/TriagingTips
[5] #debci on oftc or debian-ci at lists.debian.org
[6] golang-github-prometheus-common has an issue
============
Source: golang-github-prometheus-common
Version: 0+git20180413.d0f7cd6-1
Severity: normal or higher
Control: affects -1 src:golang-github-prometheus-client-golang
User: debian-ci at lists.debian.org
Usertags: breaks
============
[7] golang-github-prometheus-client-golang has an issue
============
Source: golang-github-prometheus-client-golang
Version: 0.8.0-2
Severity: normal or higher
Control: affects -1 src:golang-github-prometheus-common
User: debian-ci at lists.debian.org
Usertags: needs-update
============