> > >> We briefly discussed priorities for Fedora 22 and
I had taken an
> > >> action item to start an email conversation about this. So here is
> > >> what I would like to see for Fedora 22.
> > >>
> > >> 1) Get the -mcpu and -mtune flags set properly for the LE build.
> > >> Should be -mcpu=power7 -mtune=power8
> > >
> > > done, all packages that honour the Fedora system wide compiler flags
> > > use them, if they don't it's a packaging bug
> > >
> > >> 2) Have a cloud image available
> > >> 3) For BE I would like another subarch. Same packages as the current
> > >> one but tuned for P8.
> > >
> > > you mean in addition to ppc64p7? can't we just switch ppc64p7 from
> > > -mcpu=power7 -mtune=power7 to -mcpu=power7 -mtune=power8?
> > This makes sense to me as it then mirrors what we have in ppc64le and
> > it saves having more targets.
> The disadvantage of this would be to cut off users that have Power 7
> and optimized code. So why would people want to optimize from Fedora 21
> Fedora 22. You would be taking a big step back in performance. I don't
> want to suggest keeping a subarch for each type of POWER system out there.
> was thinking of keeping two. So when the next POWER arch that comes out,
> the Power 7 subarch goes away and you would have Power 8 and the new
> Power arch.
> > >> 4) Looking into if we can get Docker enabled for POWER. I will send
> > >> out further emails about this as
> > >> soon as I know more about the current development state
> > >> 5) Start the ground work for a workstation release. But I think we
> > >> should target the release for Fedora-23.
> > >
> > > yeah, the deadlines in F-22 won't give us enough time to work on it
> > Agreed, ultimately all the packages are built and as a result it's
> > possible to install and test all the main components of Workstation
> > for those that actually have desktop capable hardware to do any
> > development/testing/debug that is required to ensure all the
> > underlying workstation components and dependencies are in a good state
> > for Fedora 23.
> > It's likely there will be work needed on the X stack components like
> > mesa etc to ensure all is working.
> > >> I seem to remember hearing that there is a quite a lot of work
> > >> involved to get this build going.
> > >
> > > we should have almost everything built (eg. LibreOffice is known to
> > > fail
> > > to build), but it's not tested and if broken, it will need to be fixed
> > >
> > > One thing to not forgot is that also the mainline kernel needs to have
> > > the necessary support for the workstation class hw.
> > I think the biggest thing will be the graphics stack. While all the
> > workstation bits are built I doubt they've had wide and varied testing
> > to ensure they're al sufficiently optimised and robust for a good
> > Workstation experience.
Adding 5) update gcc to version 5. Will that be possible? It is my
that the gccgo changes needed to support Docker are in that
That is only possible if it's done as part of mainline Fedora. The
standard policy for all secondary architectures is to have identical
package set (and NVRs) to that of the primary architectures. Otherwise
it ceases to be the same as mainline and hence a fork of Fedora. That
being said the maintainers of gcc in Fedora are also maintainers and
developers upstream and will actively rebase the Fedora toolchain to
newer releases as part of the development process but they only do it
when they believe that it is ready. So if it's ready to go by the
"System Wide Changes" Change checkpoint  in time for a mass rebuild
it will be in F-22, else I suspect it'll be in F-22 else it will land
in a subsequent release.