Phase out 32bit ppc due to bugfix and maintenance burden

Thu May 15 12:37:52 UTC 2014

On 05/15/2014 02:05 AM, Al Dunsmuir wrote:
> On Wednesday, May 14, 2014, 5:14:01 AM, Dan Horák wrote:
>> On Tue, 13 May 2014 13:00:30 -0700
>> Connor Behan <connor.behan at gmail.com> wrote:
>
>>> On 12/05/14 08:11 AM, Josh Boyer wrote:
>>>> Even if build failures were the major problem, solving those isn't
>>>> actually going to result in a working ppc32 platform. There's little
>>>> invested in upstream software development on the platform. The
>>>> software will bloat over time and grow beyond the resources these
>>>> machines have.
>>>
>>> Although I'm not involved with Fedora, my suggestion would be dropping
>>> ppc versions of heavyweight packages instead of doing a full phase
>>> out. There are plenty of window managers, text editors, image
>>> viewers, media players, etc whose stated goal is to not bloat over
>>> time. Isn't this one of the main advantages of free software?
>
>> this is not feasible, but anybody is free to take Fedora packages as an
>> upstream and do a partial rebuild themselves
>
> That  partial  rebuild  being  known  as  a  remix.  The  packages are
> restricted  to  largely  what is within the Fedora git, but built in a
> different manner.
>
> It  really  does  sound  like  the practical solution for to the pcc32
> situation.  As  a  group,  we  need to come to an understanding of the
> rules  for  a  remix,  and  the relationship between the remix and the
> parent distribution.
>
> As  in  any situation where multiple groups work together on divergent
> goals,  there  will  always be differences of opinion.  While some may
> view the whole goal of the remix as a distraction and Pandora's box of
> problems waiting to happen, others will view it favourably (perhaps as
> a result of nostalgia, or their own active interest).
>
> Over  the  next interval, the ppc64 folks have immediate taks to do to
> get the ppc64 alpha into shape.  I think we can agree that is the most
> important task - the ppc32 remix  effort  can't  get in the way of the
> official ppc64 Fedora release.
>
> That   being  said, my hope would be that the ppc64 folks cooperate at
> least  passively in helping the remix to achieve its goals.  Fedora is
> not  only  the  effective upstream for the remix, but it (or RedHat in
> general) is the actual upstream for many packages.
>
> Actively  removing  support  for  ppc32  from packages presents such a
> problem.  By  some  casual  checks  of Bugzilla, I know that the build
> environment,  kernel and system configuration tools such as lorax have
> recent  ppc32-specific fixes. Other tools such as pungi have had their
> ppc32 support (for Mac and CHRP) actively removed.
>
> I  would submit that removing the ability to do live CDs/DVDs has hurt
> ppc  in  general, as it makes testing more difficult for areas such as
> video  driver  and  boot  support.  That would be a focus area for the
> remix.
>
> It  is  not  just  Fedora  where  cooperation will be helpful. Perhaps
> working  together  we  can  revive  some  of the infrastructure around
> Fedora  (such  as RPM Fusion) for both. It would be nice to be able to
> have packages such as VLC available.
>
> In  any case, I'm sure the folks that have been around for a while can
> provide  some  history, insights and advise. I'm interested in hearing
> them!
>
> My  immediate  task would be to research the formal rules for a Fedora
> remix,  and  the  normal conventions - for build, source management of
> remix-specific  changes  such  as  remix-specific configuration files,
> required  branding changes, patches (in some cases to restore stripped
> function), and spec files.
>
> My  understanding  is  that a remix can't actually be called Fedora. I
> don't  know  if this is so blank-and-white with the advent of copr and
> the  new  Fedora  world.  It  would be nice if we could stay under the
> Fedora  umbrella, but I suspect limiting the package set prevents that
> -  perhaps folks with knowledge of this (on Fesco and otherwise) could
> provide input.
>
> I  think Pidora is a good model, as it is intended to reflect the main
> ARM release, simply built for ARM6 and using a package subset.
>
> There are a number of areas where it would be useful if we could still
> have some minimal active involvement for specific packages and tools -
> gcc,  binutils,  kernel,  build  environment. This is really a case of
> wanting to make sure the upstream for the remix is able to build ppc32
> code  on  an  ongoing  basis as the upstream package set advances.
>
> For  a  number  of these, it might well be appropriate to have a small
> formal  set  of  Fedora  ppc64  packages  that  would  support  builds
> targeting  ppc32,  to  make  it  easier for the upstream to do problem
> analysis  and  fix  validation under Fedora. The remix would build the
> ship the native versions.
>
> Al
>

Hi Al.

I don't know if it needs to be a remix, but maybe looking at it as a 
spin would be an option? I'm uncertain though if that would be feasible 
from a definition point, as iirc spins need to be created from packages 
officially built and signed in Fedora proper, which would not be the 
case anymore. It's for certain some gray area here where probably FESCO 
or our Fedora legal team will have better and more concrete answers.

Overall though the whole point is not preventing anyone to do 32bit PPC, 
quite the contrary. The bottom line as i tried to explain (probably 
badly so, apologies) is that the focus of the people currently actively 
working on making the Power platform happen in Fedora have eyes mainly 
on current and future technology of the Power platform, see Steven 
Munroe's email for more details. The point is rather that we therefore 
don't have the time anymore to do all this, so something had to give 
now. And the best time to do so is prior to branching and our mass 
rebuild for a release, which is scheduled to begin on June 6 and where 
everything needs to be prepared by May 26.

All that being said, as all of us have an interest in non Intel 
architectures we'll certainly be available for helping out with getting 
the infrastructure set up and running and we're available on IRC or via 
this email list if any questions come up.

Hope that clarifies some of the reasons why we want to do this.

Thanks & regards, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Manager Core Services        | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany