Package: tech-ctte Dear TC:
I reported this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907829 and it was downgraded on the basis that the official autobuilders are multi-core. I believe this downgrade is not appropriate, for several reasons: * The informal guideline which is being used, "FTBFS are serious if and only if they happen on buildd.debian.org", is not written anywhere and it's contradictory with Debian Policy, which says "it must be possible to build the package when build-essential and the build-dependencies are installed". * Because this is a violation of a Policy "must" directive, I consider the downgrade to be a tricky way to modify Debian Policy without following the usual Policy decision-making procedure. * I also do not recognize the informal guideline being used as universally applicable, always valid, and in 100% of cases. In fact, I have yet to see why people follow such guideline when there is no rationale anywhere. Packages which FTBFS in buildd.debian.org certainly deserve a serious bug, but P => Q is not the same as Q => P. If we have a FTBFS bug that nobody can reproduce, then ok, downgrading the bug if the package builds ok in the buildds may make sense as a cautionary measure until we have more info, but a single successful build in buildd.debian.org does not ensure that the package will build in every system where the package must build. To illustrate why I think this guideline can't be universal, let's consider the case (as a "thought experiment") where we have a package which builds ok with "dpkg-buildpackage -A" and "dpkg-buildpackage -B" but FTBFS when built with plain "dpkg-buildpackage". Are we truely and honestly saying this package would not deserve a serious bug in the BTS just because it builds ok in the buildds? Surely, the end user *must* be able to build the package as well, must they not? So, in the bug above, I'm asked to accept as a fact that we have *already* deprecated building on single-cpu systems, implicitly and automagically. Let's assume for a while that such deprecation is real and suppose I would like to "undeprecate" it. What formal procedure should I follow for that? Would it work, for example, if I propose a change to Debian Policy so that it reads "Packages must build from source" instead of "Packages must build from source on multi-core systems"? No, that would be useless, because Debian Policy already says that packages must build from source. Would it work, for example, if I propose a change to Release Policy so that it reads "Packages must build on all architectures on which they are supported" instead of "Packages must only build ok in the official buildds"? No, that would not work either, because Release Policy already says that packages must build in all architectures in which they are supported. See how much kafkaesque is this? Currently, this is what is happening: Whenever someone dares to report a bug like this as serious, following both Debian Policy and Release Policy (or at least the letter of it), we lambast them, we make mock of their building environment, we call them a fool, and we quote informal guidelines which are not written anywhere. If we do this consistently, then no doubt that building on single-cpu systems will become de-facto obsolete regardless of what policy says, because nobody likes to be treated that way. But surely there must be a better way: It is my opinion, and here is where I'm asking the TC for support, that the burden of deprecating building on single-cpu systems, or in general any other thing which has always been a policy "must" directive, should be on those willing to deprecate such things, and they are the ones who should convince the rest of us, not the other way around. For example, being proud to call ourselves the Universal Operating System, we drop release architectures when it's increasingly difficult for us to support them, *not* because we dislike them, *not* because they are inefficient, and *not* because amd64 is "better". We put a lot of care when we are about to deprecate architectures, we examine the facts, the pros and the cons. The number of bugs affecting such architectures, the number of people requiring special skills for such architectures, that sort of thing. I believe this to be a much better model of what we should do if we really wanted to deprecate building on single-cpu systems, not what happened in Bug #907829. --------------------------------------------------------------------- Addendum: I'm going to summarize some of the reasons I'm told in favor of deprecating building on single-cpu systems, and why I consider those reasons mostly bogus. * I'm told that single-cpu systems are an oddity and that most physical machines manufactured today are multi-core, but this completely fails to account that single-cpu systems are today more affordable than ever thanks to virtualization and cloud providers. Just because most desktop systems are multi-core does not mean that we can blindly assume that the end user will use a desktop computer to build packages, or that users who do not build packages using a desktop computer deserve less support. We don't discriminate minorities just because they are minorities. * I'm told that building packages using single-cpu systems is worse or less efficient, and nobody would do that in 2019. I think this is based on prejudice and not on real facts. The data I've collected during the last months tells me that exactly the opposite is true: https://people.debian.org/~sanvila/single-cpu/ I would call this "CPUism", which could be defined as the wrong belief that multi-core machines are always superior and better than single-core machines. In real life, people care about the cost of things, so there are a lot of cases where using single-cpu systems is justified and useful. But even if it was less efficient (which is not), that still would not mean at all that building in single-cpu systems it not useful. For example, suppose that you have a Jenkins instance which is idle most of the time. Why on earth should this instance be multi-core and cost more if we don't care about the build time? * I'm told that if I want to see this kind of bugs fixed, I have to fix them myself, and that maintainers should not spend *any* time on fixing these kind of bugs. I can't buy the argument that maintainers can't even be bothered to ensure that their packages build properly. * I'm told that that there are bugs more important than this one and therefore this one may not be serious. I consider such reasoning flawed for several reasons: 1. If every time we have two different problems we should assign different severities to them, we would easily run out of different severities. This is called Dirichlet's principle and it's something that everybody here will understand. So it is normal and expected that two things which do not have exactly the same level of importance end up sharing a BTS severity level. 2. I have seen in fact bugs *less* important than this one to be reported as serious, with all the consequences associated to that, including the package being autoremoved from testing. Example: Wrong maintainer address in the control file: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;include=subject%3Amaintainer+address;severity=serious The package may be fully functional even if it has a maintainer address which does not work. The bug reports are not lost, the BTS still receives them. 3. If using the same severity is really a problem, we could always report FTBFS bugs as "grave" in general and use "serious" only when the build failure does not happen everywhere. Documentation says that "grave" is ok if the bug makes the package in question unusable or mostly so. What could be more unusable than not distributing the package at all because it does not build? --------------------------------------------------------------------- I would hope that the above reasons are enough to illustrate that it's not so "obvious" that we have to do this, as some people claim, and therefore it's not something that we should do "willy-nilly". Thanks.
