1:45 a.m.
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.
--
dwmw2