RFC: Primary architecture promotion requirements

[David Airlie]

----- Original Message -----
> From: "Josh Boyer" <jwboyer at gmail.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Cc: "Jakub Jelinek" <jakub at redhat.com>, secondary at 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 at 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.