Antonio Terceiro <terce...@debian.org> writes: > On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote: >> Paul Gevers <elb...@debian.org> writes: >> > I am not sure if you are addressing me or Pirate, but indeed I am >> > working on an implementation similar to what Ubuntu does (see the link >> > above about the details) which will be used as unstable to testing >> > migration blocker. debci is the worker, but all the policy logic will be >> > with britney where it belongs. And of course I try to have a full >> > release cycle to tune it. >> >> Will there be a way to override this for the maintainer? Otherwise I >> would see the danger that a buggy reverse dependency CI test can prevent >> an important update, for example if the reverse dependency uses a long >> deprecated function that is now removed. > > You can either fix the reverse dependency, or get it removed.
Sorry, I don't understand this. How can I get a reverse dependency removed (from unstable)? And why should I get responsible for poorly maintained reverse dependencies? Also, at least up to now, CI test failures are not necessarily critical. It depends on the evaluation of the maintainer which severity the problem that popped up has: often CI tests are quite picky to serve as an early indicator for problems. For example, a new package could write a deprecation warning which brings the CI test of a reverse dependency to fail. The failure is in no way critical (since the package works). But I would also not like to ignore stderr -- I *want* to have these kinds of warnings so that I can react before the real change happens, but I also see no reason to hurry up here (usually, I contact upstream and wait until they have a solution). If you now make the first package dependent on the reverse dependency, it will not migrate because of the CI failure, but I would also (as maintainer of the reverse dependency) not accept to ignore stderr. Problems like these will create additional work for all parties and are likely to make people angry. IMO it would be much better if you would either auto-create bug reports (which may be re-assigned), or to have an "ignore" button somewhere. The idea of getting informed that a certain upload causes problems in other packages is however great. BTW, there were some discussions at debconf about getting an E-mail on CI test status changes; this would also be a nice thing. Best regards Ole
