[Arm-dev] a plague farm ?

[Gordan Bobic]

On 2015-04-23 16:08, Karanbir Singh wrote:
> On 04/23/2015 02:38 PM, Troy Dawson wrote:
>> 
>> On Fri, Apr 17, 2015 at 11:07 AM, Karanbir Singh <mail-lists at karan.org
>> <mailto:mail-lists at karan.org>> wrote:
>> 
>>     On 17/04/15 14:38, Mandar Joshi wrote:
>>     >> I can work with Online/Scaleway to build the first CentOS image 
>> for
>>     >> their systems.
>>     > I would like to join the CentOS ARM effort officially.
>> 
>>     nothing official here :) people doing the work are in, people 
>> hanging
>>     around talking and hand waving are not.
>> 
>> 
>> This doesn't make any sense.
>> So, if people want to join the CentOS arm effort,  they cannot, unless
>> they are already part of the CentOS arm effort?
>> How can people change from "hand waving" to actually doing work?
> 
> as you can see, there is no real 'CentOS Arm Effort' - whatever is
> happening is being done by people on their own, on their own hardware
> using the centos sources from git.centos.org or srpms.
> 
> hoping to fix that with a plague setup, across some nodes, that people
> can ask for access to and then pool in the work being done.

Having been doing exactly this kind of thing for the past 3-4 years with
the RedSleeve project, IMO the most important part of this kind of an 
effort,
if it is to be a community effort that scales, is coordination.

Ultimately, anyone can take a F19 image and packages and write a 20
line bash script to rebuild the EL7 src.rpms using mock, then do it
again based on the packages that fell out of the first stage, and
then doing it again based on the package that fall out of the second
stage just to make sure. That just takes CPU time, and situation
today is massively less bad than it was about 4 years ago when I first
started working on it. For example, back the RedSleeve builders were
all Sheeva/Guru/Dream Plus, with 512MB of RAM and running on an NFS
rootfs.

Today you can get a single 8-core ARM board with 4GB of RAM, which
will outright outperform my entire old build farm on it's own, and
avoid the complications of running on NFS by having a SATA port
(running NFS root on the build directory caused some package self
tests to fail, at least back on EL6).

The part that is human time consuming is fixing all the packages
that refuse/fail to build. On EL6 there was over a hundred. On EL7,
I'm told it's less bad, but I'm not so sure - having tried to build
an i686 EL7 build, there seems to be a lot of spurious build breakages
so it isn't a plain, simple, out of the box "just works" process.
Having some way to distribute that effort is the difficult part to
coordinate. Raising tickets is cumbersome, and some issues often
disappear on a subsequent rebuild (and some things fail in stage 2
even though they build in stage 1 based off Fedora packages).

If anyone has a sensible method to automate such a process, I would
love to hear about it. Otherwise it takes somebody to take charge
and effectively perform such coordination as almost a full time job
until the initial complete release build is rolled out (after that
the effort reduces dramatically).


Gordan