Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Friday, January 13, 2017 05:46:41 PM Ole Streicher wrote:
> Antonio Terceiro <terceiro@debian.org> writes:
> > On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote:
> >> Paul Gevers <elbrus@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.
Reply to: