(Not sure if I can post to f-a-b; Greg, please could you forward if not?)
I think it's important for Fedora to encourage extra architectures and
not to paint itself into a corner as an x86-only niche distribution.
The 'ArchPolicy' on the wiki¹ looks like a good idea, in principle --
allowing more to asynchronously track Fedora builds and make releases
from them as long as all their fixes are in upstream Fedora is a very
good thing. I'm encouraged by it, in general.
I'm concerned by some of the details though -- and I'm especially
concerned by the fact that it seems like a retrograde step for
architectures which are currently built in rawhide but which aren't
listed in the new set of 'primary architectures', by taking away their
current build infrastructure. That's not 'encouraging extra
architectures' -- it's very much the opposite, for those architectures
which are _most_ viable of the non-'primary' set.
I'm particularly interested in the decision to stop counting PowerPC as
a primary architecture. I've heard rumours that this decision was in
part because PPC was responsible for most of the recent release slippage
-- but that doesn't seem to be backed up by the slip announcements --
the first one for FC6² lists only one PPC-specific issue in the five
problems that caused the slip, and the second one³ doesn't seem to
mention _anything_ that's specific to PPC.
The FAQ in the ArchPolicy wiki page suggests that "bugs have languished
for multiple releases without anybody even noticing". Do we have a
reference for that? Bugs _often_ languish for multiple releases -- I
don't suppose we're dropping Evolution because it's had bugs outstanding
for multiple releases, are we? And on what basis do we make the claim
"without anybody even noticing"?
The FAQ also says "there is a reason to stop doing PPC as a primary arch
until/unless it reaches critical mass once again". What, specifically,
is the reason mentioned there? What is 'critical mass' and why does it
matter? We know that PowerPC isn't as widespread as i386 but why is that
an issue? It's still very much alive -- it's as well-maintained in
kernel and glibc as i386 and x86_64 are, IBM are using Fedora as the
only supported OS on their Cell blades, and we'll have Fedora for
PlayStation3 very shortly too. There's even talk of switching certain
other big projects I'm involved with to a PowerPC processor for their
next generation. Fedora on PowerPC is very much alive.
I think the change in arch policy is overall a good thing, although
there will naturally be teething problems for the new process. I'd
strongly recommend that we don't change the list of primary
architectures at the _same_ time though. Please, let's get the new
process and the asynchronous builds in place and working _before_ we
start downgrading architectures from supported status.
(In fact, I'd suggest that we don't make such a clear technical
distinction between 'primary' and 'secondary' in the build system -- it
should all be done through the same mechanism, and the only distinction
between 'primary' and 'secondary' would be that a build is considered to
have been successful and is 'committed' only when it's succeeded on all
of the 'primary' architecture builders. But that's a technical
implementation detail and hopefully what would have happened anyway --
any suggestion to the contrary is hopefully just woolly language on the
wiki.)
I'd like to see:
1. A clear intention _not_ to move backwards for architectures like
IA64 which are _so_ close to having a 'proper' Fedora release, and
have already got FC6 ISO images built. It was looking quite likely
that if they keep up the good work, they could perhaps have had
an official FC7/IA64 release. I don't want our changes to make that
any _less_ likely, for FC7.
2. An even _clearer_ intention not to move backwards for PowerPC, which
already _has_ a 'proper' Fedora release. I _certainly_ don't want it
to be any less likely that we see an official FC7/PowerPC release.
To clarify: I don't care a hoot if it's classified as a 'secondary' arch
-- that's just nomenclature -- as long as it _does_ get built and
released. The folks who look after Fedora/PPC are used to looking after
PPC-specific issues, and the new process sounds entirely workable once
it's all shaken out. But I think that dropping PPC from 'primary' _now_,
before the process for secondary builds and in particular releases is in
place is extremely premature. To be honest, it feels like a bit of a
slap in the face for those who've been working on Fedora/PPC and IA64 to
have the goalposts suddenly moved to include a new and hazily-defined
process, even if it's a good idea in the _long_ term.
3. A commitment that the existing build machines will not suddenly be
made unavailable until/unless suitable replacement arrangements are
in place for _all_ current Rawhide architectures.
4. A commitment to quality -- in particular a commitment that
developers will not suddenly find it acceptable to commit x86-only
code (assuming little-endianness, including inline assembly etc.).
As I said, the arch policy looks like a good idea in principle -- but
please, let's test and debug the process by bringing in Aurora and
AlphaCore folks and giving them an _improvement_ in their situation. And
let's hold off for a while on making changes which have a strong chance
of _adversely_ affecting architectures like PowerPC and IA64 which are
either already shipped or very close to being shippable as part of
Fedora.
--
dwmw2
¹ http://fedoraproject.org/wiki/FedoraSummit/ArchPolicy
² https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00199.html
³ https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00431.html
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
_______________________________________________
fedora-advisory-board-readonly mailing list
fedora-advisory-board-readonly@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
