----- Original Message -----
From: "Josh Boyer" <jwboyer(a)gmail.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Cc: "Jakub Jelinek" <jakub(a)redhat.com>,
secondary(a)lists.fedoraproject.org
Sent: Tuesday, 20 March, 2012 4:08:16 PM
Subject: Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 11:58 AM, Brendan Conoboy <blc(a)redhat.com>
wrote:
> On 03/20/2012 08:24 AM, Jakub Jelinek wrote:
>>
>> I think the speed of the build hardware should be also part of the
>> criteria,
>> as all primary architectures are built synchronously. GCC on
>> x86_64/i686
>> currently builds often in 2 hours, sometimes in 4 hours if a
>> slower or
>> more
>> busy box is chosen, but on ARM it regularly builds 2 days. That
>> is a slow
>> down factor of 12x-24x, guess for other larger packages it is
>> similar.
>
>
> Our current build systems can turn GCC 4.7 around in about 24
> hours. The
> enterprise hardware we anticipate using will take that down to
> about 12
> hours. If speed of build hardware is a consideration, where do you
> draw the
> line? No secondary arch is going to get to the speed of x86_64 in
> the
> foreseeable future, so it's effectively a way to keep PA an
> exclusive x86
> club.
>
> I think the real question is, for the developers of on devel-list,
> how will
> longer builds for one arch than another affect your workflow? If
> builds on
> two architectures start at the same time, but one takes longer to
> finish
> than the other, how will that impact you? Right now you'll still
> be able to
> see and use the results of the faster build before the slower build
> completes, so are you materially impacted?
I thought about this a bit yesterday. My conclusions are that it
will
impact people in 2 cases.
1) The build works fine on i686 and x86_64 and completes in the
current
"normal" time, but then the ARM build fails some number of
minutes/hours
later. For most packages, that likely isn't a big deal but for large
packages like gcc and the kernel, I could have done exactly what you
propose and downloaded the x86 results while waiting hours for ARM to
complete and tested. If the ARM build fails while I'm doing that, I
need
to go and redo that testing after ARM is fixed because it failing
will fail
the entire koji build.
2) Updates. Submitting updates requires the entire build to be
complete
which means you have to wait for the slowest thing to finish. Having
to
wait for 12 hours effectively means you can't even test your update
until
the next day, and then after you test it you can submit it. Again,
this
is mostly compounded for large packages, but it does impact workflow.
3) chain builds in rawhide become slower.
For X we do a lot of chain + dependency building, and I think the gnome guys do as well
So now I have 12 packages to update, I need the first two to complete before I can get the
next 10 etc,
Dave.