On Thu, Apr 15, 2004 at 07:57:55AM +1000, Nathan Robertson wrote:

1. Existing packages, like the kernel needing a .config file that

produces a kernel that boots, and does something useful.

For these, there is already a maintainer, and the packages should have already gone through licensing review, etc. Provided the patches are sane, there is no reason these should be declined unless they do not DTRT. IE bandaid patches are not necessarily preferred. Fix the root of the issue if you can.

2. Adding packages that make the system more useful, and are essentially

equivalents for powerpc of packages that FC ships on x86. One example is hfsutils (needed to write a NewWorld boot partition, bugs #117512, #120811).

These now require a maintainer, packaging review, licensing review, etc. I would not expect this to happen overnight, and you really do need to present a valid need for a package addition.

FWIW, I believe that we're just "completing" the support for PowerPC, not adding a new platform, because it pre-existed in devel. A community driven release of a platform previously unsupported in any way by Red Hat would certainly be send a really good signal to the doubters out there that Fedora Core isn't just Red Hat, just like Mozilla wasn't just Netscape (and they had their doubters too).

There is more to it than just completing support for an existing arch. even the PPC stuff is aimed at IBM P-Series, and not necessarily listed as a Fedora supported arch. That said, there is certainly effort underway, as I know the Yellowdog folks have been working with Fedora as have Paul Nasrat and others to make it a supported platform. Submitting new packages to bugzilla as RFEs is certainly the right thing to do provided you have looked over the licensing, packaging, etc. But do not expect them to be blindly accepted. Red Hat has been very supportive of comminity work for alternative architectures, but it does tread new ground, and patience is required. Considering where we are in the release calendar, and the amount of pain we went through with the x86_64 release, I would not expect a PPC/PPC64 Mac release until FC3. In the meantime, building working trees, and showing that it can be supported without a ton of effort can go a long way towards getting things ready for the FC3 release cycle. I will be working with PPC64 myself, joining the efforts of those listed above. But then again, I am not a RH employee.

Justin M. Forbes Fedora Developer, "previously unsupported platforms"

Nathan Robertson (nathanr@nathanr.net) said:

2. Adding packages that make the system more useful, and are essentially

equivalents for powerpc of packages that FC ships on x86. One example is hfsutils (needed to write a NewWorld boot partition, bugs #117512, #120811).

Bugs reported against #1 types are accepted and fixed. Bugs against #2 types, it appears that Red Hat engineering people are unsure as to what they are expected to do. Quoting bug #117512, Bill Nottingham:

"Hm, I suppose there should be some sort of policy on packages not required for any officially supported arch."

This is not the only example I've come across of this, just the latest one that has led me to post this message. Can somebody senior from Red Hat give us some idea as to what the story is here?

Hey, come back here, I can't reach you with my cane.

Basically, there's never been a PPC release of Fedora, or even of Red Hat Linux/Red Hat Enterprise Linux. So, it would be adding a package that doesn't really apply to anything else in the current 'family'... yet.

Moreover, until the external contribution infrastructure is up and running, any new package addition requires someone to shepherd it though the build system, act as a bug bucket and patch clearing house, etc.

Mainly for the second reason, at this point I'd think it's best to be very conservative when it comes to adding packages, *especially* ones that aren't going to be used in the current planned FC2 trees (x86 and x86-64). Unfortunately, at this point it's a zero-sum game - time spent by someone pushing through packages such as this is time that can't be spent fixing other bugs. So, without someone internally (*sigh*) volunteering to deal with the package, it may not make sense to add it.

Someone did volunteer, however, and hfsutils should be in tomorrow's tree.

Once the contribution infrastructure gets going, this situation should be a lot simpler.

Bill