Bug#932795: How to handle FTBFS bugs in release architectures

[Santiago Vila <sanvila@unex.es>]

I'm really sorry for the late reply. The reason I was taking so much
time to answer the question "how many packages are affected" is that
I'm *also* tracking packages which FTBFS randomly:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?correspondent=sanvila%40debian.org;dist=unstable;include=subject%3AFTBFS+randomly

At this moment I have (pending to be reported) around 50 packages
which fail in 1-cpu systems (but not 2-cpu) and around 50 which fail
in 2-CPU systems (but not in 1-cpu). Most of the time the failures are
random, but I still have to check that it's not really "FTBFS always".

So yes, doing QA is hard.

Now this bug is closed and I'm not sure if I should still answer the
question about number of "affected" packages, but I didn't want to
leave your counterpoints unanswered:

Simon McVittie wrote:
> I have two counterpoints to that.
> [...]
> I for one would prefer to have a version of gcc that can only be built
> on multi-core machines rather than no version of gcc at all.

The problem with such kind of reasoning is that you could equally
apply it to many other items in the list of Release Critical Issues:

https://release.debian.org/bullseye/rc_policy.txt

A few examples:

I for one would prefer to have a version of ${some-useful-package} in
the archive which requires the existance of some files in
/usr/share/doc in order to function rather than no version at all.

I for one would prefer to have a version of ${some-useful-package} in
the archive which does not have a useful extended description rather
than no version at all.

etc.

I hope you see what I mean. Release Policy is a subset of Debian
Policy, made of those items which we consider "really must", and the
purpose of Release Policy is precisely not having to discuss over and
over again if some bug is RC or not: If an item is in the list, then
it's RC, at first at least.

Then we can make exceptions if we want, of course, but exceptions are
also regulated by Release Policy:

> Further to this, certain issues may be exempted from being considered
> release critical for bullseye by a release manager. This is expressed
> by tagging the report "bullseye-ignore"; this should not be done without
> explicit authorisation from a release manager.

That's what I would expect people to do when they disagree that a
FTBFS bug in a release architecture is serious. There is a procedure
for that, it's not automatic, and downgrading the bug without asking
for the appropriate ignore tag is a little bit like cheating.

Ideally, this (or using the imaginary new Build-CPU control field)
could be like Pre-Depends, you have to ask for permission before
adding one, and there needs to be a very good reason for it.

> My second counterpoint is that I don't think we can claim to be
> treating "minimize the money spent by users who rebuild the archive"
> as an important goal in general,

The problem with that is that we are not speaking about a mere
"optimization", it's the difference between A and B, where A is

"To be able to build *any* Debian package, you will need
a machine with 100GB of disk, 12 GB of RAM and 1 CPU"

and B is

"To be able to build *any* Debian package, you will need
a machine with 100GB of disk, 12 GB of RAM and 2 CPUs"

I believe the difference between A and B is large enough that it would
be a pity if we have to go for B instead of A because we were unable
to fix a few packages before the release.

Thanks.