On Fri, Sep 07, 2018 at 10:46:36AM +0300, Adrian Bunk wrote: > On Thu, Sep 06, 2018 at 10:46:07PM +0200, Santiago Vila wrote: > > > You will have noticed that we usually report FTBFS bugs when a package > > fails to build in any "correctly" configured autobuilder, we don't wait > > for the build failure to happen on buildd.debian.org. > >... > > No release architectures has a single-core autobuilder at buildd.debian.org. > > And it is completely out of the discussion that any would in the future.
I was trying to argue that the official autobuilders are not, and should not be, the only measure by which we consider a bug to be serious or not. And I put a very simple example: Imagine that all our amd64 autobuilders are Intel and there is a package which FTBFS on AMD. Are you really trying to tell me that the FTBFS bug would not be serious "because it does not happen on buildd.debian.org"? I would like to believe that you would say "baseline violation", since that's what you said (and I fully agree) here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906697 Now you could maybe argue that using a package and building it are "different" things. And they are in fact different things: Being able to build a package is actually *more* important than being able to use it, because building is a *precondition* for use. If I try to build a package and it fails, there is no package to use. This is the very reason why we consider a FTBFS to be serious. The package is completely unsuitable for release. It prevents the package from working at all because there is no package to use at all. Now the question: Do you want to deprecate using Debian on single-core, or only building Debian on single-core? > > But that's only the best case scenario. The worst case scenario is > > that you build all packages using 2 CPU but only a proportion of them > > support (and benefit from) parallel build. For those who don't we are > > wasting completely the extra CPU. > > > > So no, it's not cheaper in general, and it may be even more expensive. > > Which cloud provider are you using? I have actually used many of them. The most popular ones like vultr, digital ocean or linode offer all-in-one packages in which more CPUs means more RAM and of course more money, usually in powers of two. For example, if we compare the most expensive single-CPU with the cheapest multi-CPU on Vultr, that means going from $10/month to $20/month: https://www.vultr.com/pricing/ This is double the price for something which may or may not take half the time (depending on the package). So yes, I already did the math and definitely building on several CPUs is not cheaper. On GCE you can pay for CPUs and RAM independently, but CPUs are generally more expensive than RAM: https://cloud.google.com/compute/pricing (The disk here is very cheap: $0.04 by GB-month). Why are we discussing about the price, anyway? Are you trying to discriminate against people who build on single-cpu because they are rich, because they are poor, because in your opinion they don't use their resources efficiently, because of what? Thanks. -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
