Marc Haber <mh+debian-de...@zugschlus.de> writes: > I would feel a lot less uncomfortable if the teams who are using > automated tools to auto-file RC bugs for third-rate policy violations > which will auto-remove a (99,99% of the cases) perfectly working > package from testing in a time where a maintainer would probably not > dare to touch his maintainer scripts for fear of creating a really RC > bug which will in turn get the package auto-removed from testing would > refrain from doing their auto-foo during the freeze.
I would rather prefer to get the results of these tools *before* the freeze. In the Jessie release process I had the impression that many tests were done only after the freeze, putting some unneeded pressure to the maintainers. It would rather be nice to run them *now*, or even a few months earlier. > I do appreciate automated tests, and while I think it can be discussed > whether the policy violations found by those automatic tests need to > be RC, I firmly believe that these tools should not be used as a > weapon against packages. They should rather be part of the CI process, also allowing to discuss them during the normal evolution, not in the pressing time of a release. But this is based on my subjective, unproven feeling. >>The goal of autoremovals is to provide an incentive for people >>to deal with problems in their packages _early_. > > Managerspeak. Even at work I hate people who talk about giving > "incentives" while they actually threaten. The problem I see here is: why doesn't the RC bug appear _early_, but maybe only during freeze? >>And as I said previously: if a maintainer of a dependency of yours >>doesn't care: NMUs for RC bugs have a far lower threshold - even >>0-day NMUs are possible if the maintainer is really completely >>asleep. (DevRef 5.11.1) > > So this is a method to force people to take additional > responsibilities for dependencies as well in addition to the > responsibilities they have taken voluntarily? Well, _this_ will > clearly motivate people. I must say that I see no other way: if a dependency of your package has n RC bug, nobody fixes it and you want your package to be kept in, you have to deal with it yourself. I would only propose (and hope) that from the release team it is also accepted to re-upload my own package rebuilt without the buggy dependency -- very often dependencies are optional, and it may help to cut the dependency on a broken, poorly maintained package. For example, many of my packages have lots of dependencies just to run extensive build time tests. Removing them would not make the package worse. Or it may be better to have the package with reduced functionality that to get the package removed completely. Best regards Ole
