On Friday, January 13, 2017 05:46:41 PM Ole Streicher wrote: > 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.
Probably the simplest way to avoid problems with systems like this is to remove any autopkg tests your packages are shipping. Scott K P.S. Perverse incentives FTW.
