Hi Paul, On 27.04.2018 22:25, Paul Gevers wrote: > I wonder if you missed this piece of my comment (do you want a new bug > for this?): > > On 26-04-18 17:54, Paul Gevers wrote: >> but >> probably also that starlink-votable-java needs a versioned breaks on >> starlink-table-java, as for starjava-table, also starjava-table packages >> need to be upgraded for the test to pass. > > starjava-table fails¹ (as expected) with the updated package (second try > for trigger starjava-votable/2.0+2018.04.17-2).
I didn't miss this. As I wrote in my last comment: starlink-votable-java works nicely with the old starlink-table-java. 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. 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. 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. Best regards Ole
