Dealing with PPC in Fedora 9(+)

[Jesse Keating]

On Sun, 11 Nov 2007 02:45:47 -0500
David Woodhouse <dwmw2 at infradead.org> wrote:

> 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.

Sure, stuff has happened.  Honestly we hoped that it would happen
sooner.  I'm still not considering turning PPC completely into a
secondary arch precisely because secondary arch stuff isn't ready and
another arch hasn't played guinea pig for you.

> 
> > 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.

I'm making a compromise.  I don't want to turn PPC into a full
secondary arch yet either, however in the places that really aren't
related to the buildsystem there is no reason why PPC can't take care
of itself.

> > 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?
 
Not quite.  Some of the same tools are involved, but are ran
differently (so that isos are made), with different configs for the
Fedora spin, and rawhide doesn't include Live images.

> 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?

No.  The same tools have been used for Fedora 7 and 8.  They've been
developed on and improved, but its the same tools.  They have to be ran
on the arch they are composing, which means we can't easily use setarch
to produce ppc trees/media like we do on x86.  This requires those of
us doing the compose to maintain a second machine and thread the output
back into the other arches.  There is also validation of the bits, time
spent syncing them around, etc...

> 
> > 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.

Will's repeated pleadings for people to help out have been missed?
That's a shame.

> 
> >   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.

I'm not so sure that this is the "important" part.  It's really quite
simple.  If you're built from our bits, you can call it Fedora.  Put it
in a directory structure that would fit well with the rest of the
mirror structure so that if mirrors chose to, they could spend their
bandwidth and disk space on mirroring ppc (or other secondary arches).

> 
> > 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?

-1 Troll.  Whether the builds happen as part of a primary arch set
(which we aren't changing right now), or they happen as part of a
secondary arch build set, the maintainer is going to see a failure.
They're going to care as much about it as they did in the past.  Only
now there would be a more official set of people to help them out with
said arch issues.

> 
> 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?

Again troll, but in all reality we have extremely few ppc rawhide users
to begin with, and problems show up and stagnate for MONTHS before
somebody like me or Jeremy find it as part of tree validation stuff.
What I want is for it to be clear that the quality of PPC is entirely
up to the the user base for it.  All too often the user base, even your
self, just rely upon somebody else to find the problems, and you just
come in late in the game or the release and see "yep, everything is
still fine.  No need to pay attention to alpha/beta/rawhide, it'll just
work at release time and I don't have to care.".  If every arch did
that we would miss the majority of the bugs.  The difference is on
other arches, we have a very large set of users using it every day and
testing it every day and reporting all the problems they find.  We hear
crickets from the ppc community.  Advertising PPC as a secondary arch
is a clear sign that the fate of ppc relies upon the users of that
arch.  If they don't step up and pay attention and report when there
are issues, they'll likely get missed and wind up in the final release.

> 
[ snip ]

> 
> 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 want to set the expectation that the BugFreeness of PPC relies on
them the users actually using rawhide and the test releases to find the
bugs, like the x86 folks do.  The bugs we find on x86 will be fixed for
free on ppc, but if nobody is using the ppc development trees then any
ppc specific bugs are going to fall through and ruin that BugFree state.

> 
> 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.

Then /do/ something about it.  Don't just rely on others to find your
bugs, don't just rely on the release team to find all your bugs at the
last moment, don't expect QA to spend a ton of effort finding your bugs
when a very tiny amount of people actually consume the work.

> 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.

That doesn't have to change.

> 
> 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.

The way to accomplish this is to put the responsibility of producing
the release upon those that would consume it.


-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20071112/e244ead7/attachment.bin