On Fri, 2007-11-09 at 14:06 -0500, Jesse Keating wrote:

Now that Fedora 8 is out, I'd like to make a suggestion with regard to PPC. It's no secret that we've been talking about dropping PPC. First it was all together, then it was so that it could be come a secondary arch. So far, we've failed to execute.

That's not entirely true. We agreed that we would not change the status of PowerPC until one new 'secondary architecture' had been added. We have been working towards that goal, and progress has been made. Not all of it has been entirely sensible, on the build system side, but stuff _has_ happened.

Starting now, I'd like to treat PPC as a pseudo secondary arch. This is because the secondary arch framework just isn't in place yet.

I would like to stick to the agreement to keep PPC as a primary arch. This is _also_ because the secondary arch framework isn't in place yet.

What would this mean? We'd continue to build ppc binaries as if it were a primary arch, this requires no change to Koji. We continue to make rawhide trees of it, this requires no change to buildrawhide (mash, pungi).

Sounds good so far :)

However, come release time (Alpha/Beta/Pre Release/RCs/Final) it would fall upon a secondary arch team for PPC to create release trees and isos of the bits.

I'm not sure exactly what that means, because my visibility into those parts of the release process has always been somewhat limited -- in fact I usually mostly ignore the rc1/rc2/rc3 or alpha/beta/prerelease or fish/monkey/turnip or whatever you want to call them this week, and just poke at rawhide. I've always considered the 'RC' spins to be just a confidence trick to get more victims^Wusers to install the stuff.

What does it actually take to create the RC spins? I thought it was mostly just a case of running the same tools which run automatically to build rawhide each night?

Given that those tools seem to change from release to release, it sounds like having that done by a separate team is just make-work stuff, for now. When we have other secondary architectures we'll want some kind of process for it, but at the moment it sounds like it would just be easier to keep running the same script three times instead of twice, surely?

It would fall upon this team to QA the bits.

It certainly makes sense for myself and other volunteers to take a more active and _visible_ rôle in QA, I agree. I've been vaguely aware of text matrices in the wiki, but I've never been sure that it would be welcome for me to simply mark stuff off as 'tested'. I try to just make sure that when it _is_ tested, it works.

It would fall upon this team to host the bits for download at release time (if no suitable framework exists for hosting the bits elsewhere at various release points, rel-eng could insert them into the normal tree structure as a last resort).

Let's not do this yet -- the hosting, and surrounding issues about "Fedora" branding and mirroring, is a fairly important part of the "secondary architecture infrastructure" which we agreed should be in place and working for at least one other architecture _before_ we switch PowerPC over to it.

We would clearly advertise that PPC is to be considered a secondary arch.

Advertise to whom and for what purpose? Precisely what is the message that you'd be trying to convey? What effect would you want to achieve? The term 'secondary arch' doesn't really mean a lot, in and of itself.

Do you mean that you'd want to advertise to Fedora packagers that we don't really care about stupid endianness bugs any more, and they can be much more sloppy in their code?

Do you mean that you'd want to advertise to Fedora users that we won't bother to look at bugs which happen to show up on PowerPC, unless they're also reproduced on some other platform?

Do you mean that you just want to stick your fingers up at PowerPC because you think RISC is the work of the devil? :)

Do you want to lower the expectations of Fedora users, so that they don't expect Fedora/PowerPC to be as BugFree™ as Fedora/i386?

I think all of those are bad ideas. The first two because they'd reduce the quality of Fedora code _overall_, the third because it's silly, and the fourth because if Fedora/PPC is significantly lower in quality than Fedora/i386 then we shouldn't release it as "Fedora" at all.

Ok, admittedly they were straw men... what _do_ you want to be saying?

We would do this /now/ so that there is enough time for interested parties can form a team and have it in place to handle bug reports, composes, etc...

Is there an issue with the way that bug reports are handled already? We keep the FE-ExcludeArch-ppc bug nice and empty, and the ppc64 version as empty as it needs to be given that we favour 32-bit userspace.

Let's work towards making sure that F9 QA is done for you by those who care about the platform. Tell us what you need done in that respect, and we'll make sure it happens. But let's not change the hosting or other arrangements until another arch has led the way, as previously agreed.