On 7 March 2015 at 04:11, Peter Robinson <pbrobinson@gmail.com> wrote:
Hi All,

I know this has been discussed around the traps here and there but I
thought I'd take it to the list for a more directed discussion.


Thank you. I would appreciate a directed discussion on this. We brought this up at the last EPEL meeting (which I haven't posted the minutes too :/.) and were going to bring it up for a vote.
 
It's been a long time since there's been a new architecture added to
RHEL. With RHEL 7.1 there's been support added for POWER Little Endian
(ppc64le) and with the aaarch64 PEAP (I have no idea about RHs plans
there) plus the i686 CentOS effort it's possible that there might be
demand in the future for more architectural additions so I figured
it's probably a good time to discuss requirements for the addition of
new architectures to EPEL.

In the case of ppc64le the RHEL release is closer to x86_64 in
features and functionality than ppc64. It also has the advantage it's
also little endian so a number of the issues that are seen with the
big endian builds are a non event. IBM have been doing some builds and
filing bugs [1] for build issues.

Just to note the initial 7.1 ppc64le release of RHEL has a different
distag to el7 but this should be resolved by 7.2 beta.


Here are the issues that I would like to see addressed for any architecture. Various people have said that I am 'PM' of EPEL for the time being, so I would like to think about this as I would hope a good product manager would. [This is also where I get to be removed forcibly]

1) Who is championing an architecture? 
2) Where do developers get access to hardware that they can debug issues if they want to. 
3) How do we remove an architecture for whatever reasons? [Possible ones could be it turns out that CentOS i686 is dropped after one subrelease... or PPC64be is dropped by IBM because everyone moved to PPC64le. Or Itanium3 comes out and no one wants x86_64.]
4) Is there a way to break out an EPEL-secondary architecture where these sorts of things are done? [I believe the answer is NO, but it is a question I expect would be asked.]

My main concern on architectures are the following:

1) Every architecture we have is one that potentially blocks other builds. If the PPC builder which is only used for EPEL goes down.. regular Fedora builds have been affected in the past. I believe those problems have been fixed in koji but it is a non-zero risk.

2) Even if it has been fixed to never effect Fedora builds.. it is more hardware which needs to be maintained in the primary build network and downage of any architecture affects all EPEL builds.

3) The people who are championing this are the guys who have to do a lot of the hard work of getting it going.. but are the most overworked guys in Fedora with just Fedora primary and secondary architecture work. They are not the people who have time to be answering developer questions about why some java app doesn't compile on ppcle which requires an IBM developer to go 'ooooh yeah you need to patch that twiddly bit.'  I realize that there are various ARM and PPC developers who do that for Fedora in their mailing lists. I would like to see someone from there saying 'yeah we will help when we can' for any architecture.

4) Because EPEL doesn't do releases and there is no want from release engineering to do releases in EPEL.. adding an architecture or stuff is easy. removing it is a completely different story. From what Dennis and others have said, this is non-trivial to 'not enough beer in the world' level. If anything turns into an Itanium where we had support up to one release and then no more... or some similar problem.. it is more work for the overworked guys.

--
Stephen J Smoogen.