RFC: Primary architecture promotion requirements
blc at redhat.com
Tue Mar 20 17:57:37 UTC 2012
On 03/20/2012 10:27 AM, Kevin Kofler wrote:
> Then let's rediscuss making ARM a primary architecture when that happens.
> Right now the speed is just not acceptable.
Really? You're going to base your entire opinion on build time data on
inappropriate hardware for one package without knowing even what the
factors are in the build time? What if 50% of that time was due to test
timeouts that require a simple fix? Please turn down the hyperbole dial
and think before jumping to conclusions. If all Fedora is to you is a
means of turning source code into binaries at lightning speed, x86 is
great for you. I'm pretty sure Fedora is more than that. And if Fedora
is going to be relevant in a few years time, it better support the CPU
that is inside the computers everybody is buying today.
> That alone means it's not a solution.
> Also note that not everything in builds is parallelizable:
> * not all upstream build systems use make -j,
But most of the big packages do.
> * configure (or cmake etc.) and make install are usually not parallelized,
Make install speed is going to be the same. There will be no
appreciable difference IO difference. It's entirely storage-speed bound.
> * often there are makefile dependencies requiring at least some amount of
> etc. So even if you have -j working, you STILL need a comparable speed in
> ONE core compared to the x86 builders.
Er, no, that's what you believe you need. I need packages to build in a
period of time that works for the affected developers. You're
responsible for some packages I believe so why don't you start by
looking at how you would personally would be affected and talk about
that? With as few exclamation points as possible, please. What's your
slowest building package? We can probably extrapolate how long it will
take to build with first generation ARM server hardware. From there we
can talk about how that affects you work flow as well as how to handle
it being delayed. Thanks,
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com
More information about the devel