[Debian-astro-maintainers] Bug#896977: starlink-votable-java: new version misses versioned depends on packages from starjava-fits

[Paul Gevers]

Hi Ole,

On 27-04-18 22:51, Ole Streicher wrote:
> I didn't miss this. As I wrote in my last comment: starlink-votable-java
> works nicely with the old starlink-table-java.

Oops, I forgot to check the bug (why, o why doesn't the bts enable us to
auto-subscribe to all the bugs we report, ah right, Debian is a do-ocracy).

> It is just the tests that
> need to be updated, but for a user both packages play together well. In
> fact, the problem is *not* starlink-votable-java in this case, but it is
> a bug in starlink-table-java. It is already buggy, the bug just does not
> show up in the CI test with the old version of starlink-votable-java.
> And an update (for starlink-table-java) is already uploaded.

Ok

> IMO this is a problems with the CI tests: it is great to have the tests,
> and to see where we have incompatibilities. However often the problems
> shown are minor, and so for migration I would like to have a "that is
> OK" button there, which overrides a migration veto.

Migration isn't blocked (for now). Please read my proposed
announcement¹. In the far future, if/when we do block migration, filing
a bug against release at debian.org package can get you a badtest hint.
There is also bug 851558, which request the dep8 specification to an "do
not block migration on this test" feature. If individual DD's need
access to the "this is OK" feature, we'll need to come up with a
mechanism for that with the release team. In the current system, a
badhint test is needed, which can be created by them (so a bug against
release at debian.org could get you that; yes, work for humans, so not
perfectly for what you have in mind).

> Usually we allow packages to migrate when there is no "serious" bug, but
> many test failures would normally indicate only "normal" or "important"
> bugs, and should therefore (at least as an option) not hinder migration.
> Restricting the tests to RC stuff is also not a good solution here,
> since then I would lose a big utility for my QC. And usually I can't
> weight the importance for individual CI tests beforehand myself: they
> are written by upstream, and sometimes (astropy) they are so many
> (~10.000) that I have no chance to sort them. I usually check the result
> when I see a failure, and often need to contact upstream to estimate the
> severity of a failure.
> 
> So: Not all CI test failures show a "serious" (RC) problem with the
> upgraded package. In many cases the problem is minor, and the migration
> logic should take this into account.

Ack. That is the reason why we set up britney like we have, and why the
bugs that I file² are nearly all at the severity normal (some even
wishlist). I try to judge the severity when I file the bug, by trying to
understand (from the logs and changelog, often also the test code).

Paul

¹ https://gobby.debian.org/export/Teams/Release/using-autopkgtest
²
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-ci@lists.debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-astro-maintainers/attachments/20180428/d9c70570/attachment.sig>