RFC: Primary architecture promotion requirements

[Kevin Kofler]

Brendan Conoboy wrote:
> 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.

Those numbers were just one example, which reflects the trend I've 
experienced (also following the efforts to build KDE packages on the 
secondary architecture infrastructure) fairly well.

And in addition, build time is just one of the reasons (though the main one) 
why I don't think ARM should be a primary architecture.

> If all Fedora is to you is a means of turning source code into binaries at
> lightning speed, x86 is great for you.

Indeed, x86 is great for fast builds, which are an important part of Fedora, 
because they're part of what allows us to deliver current software quickly 
and efficiently (e.g. we're usually the first binary distribution to offer 
the latest KDE Software Compilation bugfix release as an official, tested 
update – don't forget that "First" is part of our 4 'F's).

> I'm pretty sure Fedora is more than that.

Sure, but that doesn't mean build times are not important.

> 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.

1. It supports it. As a secondary architecture. Why is a secondary 
architecture not good enough support? (And why can't those issues be fixed, 
benefitting all secondary architectures?)
2. We can discuss making it a primary architecture "in a few years time", if 
ARM is really that successful by then. Why now? There's nothing requiring 
the change to be made NOW.
3. Your definition of "computers" is not the same as mine.

> 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?

Probably kdelibs.

> 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.

kdelibs is the first package which needs to be built for KDE SC updates and 
we cannot start building any of the others before it is complete. (And also 
note that there are some other interdependencies, e.g. several modules also 
depend on kde-workspace, which also takes a while to build.) Last I checked, 
Rex Dieter reported that kdelibs took many hours to build on the secondary 
architecture ARM builders even with apidocs disabled; with apidocs enabled 
(which is how we build it on the primary architectures; also note that the 
apidocs build process is NOT parallel), it was taking so long that it timed 
out entirely.

And in addition to individual packages taking too long to build, I also 
expect the aggregate latency due to many small package builds all taking 5 
to 10 times as long to waste a lot of my time. I already find it painful to 
wait for my builds to complete even now!

        Kevin Kofler