On 03.12.18 10:02, Sebastiaan Couwenberg wrote: > On 12/3/18 9:54 AM, Ole Streicher wrote: >> On 03.12.18 09:41, Sebastiaan Couwenberg wrote: >>> hdf5 is unable to migrate to testing because gnudatalanguage >>> autopkgtests fail. Test failures indicate that the package is broken, >>> and not suitable for release. It should be removed from testing until >>> the test failures are fixed, which also allows hdf5 and its rdeps to >>> migrate to testing. >> >> That is currently in the decision of the package maintainer. Neither the >> policy nor the RC document you cited list CI test failures or migration >> delays as a possible cause for severity "serious". >> >>> As announced the autopkgtest delay is increased exponentially which will >>> block packages from getting into buster before the final freeze. We do >>> not want that to happen, but your package is not allowing hdf5 and its >>> rdeps to migrate even though there is nothing else preventing this part >>> of the transition. >> >>> Fix your failing autopkgtests or remove them. Not fixing failing >>> autopkgtests in your package that prevent its dependencies from (timely) >>> testing migration is very unfriendly (to phrase it very mildly). >> >> I totally agree, I am affected as well, and I am working on it. You >> shouldn't think that an "important" bug does not get attention. But this >> also does not reason the severity "serious". > > Yes, it is. Your package is broken and needs to be removed from testing > as soon as possible, as it negatively affects its dependencies.
The package works well, with a few things that do not work. This is what we call "normal" or "important" bugs. "negative effects" is not "breaks". Migration delays are not breakages. > important severity does not trigger autoremoval, serious does. Sure, so what? > The RC policy hasn't been updated for autopkgtests yet, but I expect > failing tests to become an official reason for RC severity as that > removal from testing of that package will be the only way to let its > dependencies migrate to testing (without release team hints). Unless this is the case you can't cite that as an argument for being RC. Also not the policy. > If a fix is forthcoming, why not let gnudatalanguage be autoremoved from > testing, and let it migrate again when it has been fixed? > Do you think that keeping your package in testing is more important than > all the other ~100 packages involved in the hdf5 transitions? According > to popcon it's not. About 30-40 of those are mine, BTW. And I am still unsure whether hdf5 is not really the cause of the problem yet, since it is the HDF5 test case in gnudatalanguage is the only one where I don't see a reason for the failure yet. Just "let us migrate" is the wrong way here -- the CI migration delays are to find out where the problem is before. Best regards Ole
