Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Mon, Jan 16, 2017 at 11:45:42PM +0100, Markus Koschany wrote:
> No, this is not current practice. But you are obviously trying to force
> it this way by all means necessary. Nobody asks you from refraining to
> report those kind of bugs but what I and other people are seriously
> questioning is your handling of severity levels.
Sorry, no. You downgraded "missing build-depends"-type bugs several
times, and somebody else had to tell you that they were RC.
Example: gnupg. You did not believe that gnupg was not essential and
argued and argued and argued until a Release Manager told you clearly
that missing build-depends are RC.
There was also a missing build-conflicts bug that you downgraded and
somebody else had to tell you that it was wrong as well.
So it's not me who is handling severities wrong.
> You always assume RC
> severity even when it is proven that the package works and builds fine
> for the majority of people.
No. I assume RC when it is a FTBFS bug and I can reproduce it in
several different computers.
There is no such thing as a "majority of people" when your single and
only source for "buildability" is buildd.debian.org.
A successful build in buildd.debian.org means *nothing*.
Buildds may have packages installed which are not build-essential.
Buildds may be running jessie while I am already running stretch.
Etc.
> You don't care what maintainers think about
> the issue. Many people, me included, get annoyed and then resolve this
> "issue" by disabling the responsible test and focus on more pressing
> matters. There is nothing wrong with tests per se which try to catch
> _real life_ issues though.
Sorry, it is not responsible at all to have a flaky test make the
whole build to fail.
If you get annoyed by flaky tests making the build to fail, do not let
the test to make the build to fail, but don't blame me for the annoyance
that the test fails.
Thanks.
Reply to: