[EPEL-devel] Process for supporting of new architectures

[Stephen John Smoogen]

On 7 March 2015 at 04:11, Peter Robinson <pbrobinson at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20150307/6a03e306/attachment.html>