RFC: Primary architecture promotion requirements

Brendan Conoboy 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
>    serialization

Uh huh...

> 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 mailing list