Dealing with PPC in Fedora 9(+)

[David Woodhouse]

On Mon, 2007-11-12 at 09:14 -0500, Jesse Keating wrote:
> > 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.

I certainly agree that we can reach such a compromise on the rel-eng/QA
side.

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

OK, cool. This kind of thing has been black magic for so long that I'd
mostly given up on trying to follow it. I may need a small amount of
babysitting, because I'm not very clever. But it sounds like it makes
sense for us to handle the composes for ourselves too, as you suggest.
We'd still want to put them in the 'normal' download location though,
for now.
  
> > 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.

Yes, they have. And yes, it is. If that's my fault, then I apologise --
Will, please do feel free to Cc me (and fedora-ppc at lists.infradead.org)
directly if you need assistance with anything related to PowerPC.

And if we're not paying sufficient attention to fora which we _should_
be monitoring, please point us at them and we'll try to do better.

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

Not "the" important part, I agree -- but "an" important part. One of the
things we want to be tested out by a guinea pig first :)

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

Absolutely -- and in fact we already _have_ such a structure. Mirrors
can, and do, already choose which architectures to carry. I don't think
we need to change the location for Fedora 9. Especially if it's likely
to change again when we set it up properly for "secondary architectures".

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

 <...>

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

Thanks, Jesse. Nice to know my work is entirely worthless. Here was I
thinking that I'd been running rawhide, and reporting and fixing bugs
(most of which didn't turn out to be arch-specific anyway).

Maybe I just imagined it.

 <...deep breath...>

I certainly have no intention of relying on somebody else to find
PPC-specific problems. I start testing rawhide at about the same point
in each cycle that I've _always_ started testing rawhide, even in the
days where I was playing with RHL on i386. I was not aware that I came
to it "late in the game", and the bugs I find when I do this usually
turn out not to be PPC-specific. Perhaps I should start earlier.

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

I'm dubious about the validity or relevance of that observation. You
could just as well say that we hear crickets from the Kerberos-using
community. If I file or fix a bug which isn't arch-specific, I don't
mention PowerPC. Do you count me as an i386 user when I do that?

Arch-specific bugs make up a _small_ proportion of the total, in my
experience.

Anyway, if we agree that the PPC SIG will take on the task of QA for F9,
then that point is moot, is it not? If it isn't installable and "good
enough" in time, then it doesn't go out in sync with F9/x86.

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

OK, that makes some sense; thank you for clarifying. That being the
intention, the best time for this 'advertisement' doesn't seem to be
_now_, as you suggested -- it would be better to do it when we put out
the first release candidate tree. _That_ is when we want the testers to
be paying maximum attention.

It's also an issue which shouldn't directly concern you -- it's up for
the us (the PPC SIG) to whip our users into action when we believe we
need more from them.

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

<...another deep breath...> 

OK. Let's do it that way. I wish I'd thought of that earlier :)

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

OK. The PPC SIG will take on the responsibility of producing the
composes and doing the QA on them, for the F9 release. If we don't
manage that, it won't go out on PPC.

As you said, we don't need to make any changes to the build system or
the way rawhide is handled right now.

I don't believe it's realistic to make changes to the hosting and
mirroring arrangements either -- let's stick with the plan of keeping
them in the 'normal tree' which you called a last resort.

We'll plan to have each spin ready on time, so it can go out fairly much
synchronously with the i386 and x86_64 releases -- and more to the
point, with precisely the same package set. If for some reason we slip,
let's impose a rule that we may not ship any packages in the PPC spin
which are not in rawhide (for the RCs) or f9-updates (for the release).

OK?

-- 
dwmw2