Antonio Terceiro <> writes:
> On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote:
>> Paul Gevers <> 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

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


Reply via email to