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(a)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