RFC: Primary architecture promotion requirements
jkeating at redhat.com
Tue Mar 20 22:33:02 UTC 2012
On 3/20/12 2:33 PM, Brendan Conoboy wrote:
> On 03/20/2012 01:03 PM, Jesse Keating wrote:
>>> As an example, the same koji server handling x86 builds handling ARM
>> Only the koji hub would be the same, the arm builders would be different
>> machines. This isn't all that different from having the primary hub
>> trigger the arm hub to start a build on the arm builders.
> So in principle, do you object to the same koji hub being used for ARM
> if ARM is still SA?
I'm not really sure how to process that question. As a current
secondary arch, the primary hub is still the trigger point for the vast
majority of the builds that will happen for arm. A successful build on
the primary hub will trigger (through koji-shadow) a build on the
secondary arches. I'm sure you're (painfully) aware of this.
I don't understand how the same koji hub could be used for arm while arm
is still SA differently than above.
>> The PPC builders are there, or at least were at some point, why not
>> propose moving some arm stuff there for the arm secondary arch effort?
>> I don't see SA/PA mattering as much here. It's up to QE what they want
>> to take on and what they point automated tooling at.
> The sense I'm getting from your reply is that the PA/SA designation is
> almost decorative, that a secondary can do anything a primary can,
> except inhibit the progress of builds.
Mostly. It'll take effort on the part of the secondary arch to engage
these other parts of the Fedora project to convince them to pay
attention to your arch. If you were a primary, they're essentially
forced to care. Enticing them to care as a secondary arch goes a long
long way to show that you're ready to be a primary arch and that the
promotion would not cause much ripple effect.
> So, if the Fedora ARM team fixes
> all broken builds, brings in all the QE mechanisms, engages the Fedora
> system at every level of the organization, solves the the build time
> performance issue, and otherwise keep at it until we're functionally
> indistinguishable from PA, *then* it's time to have the PA/SA
> discussion. Is that right?
That does seem right. Just like the old adage, dress for the job you
want, not the one you have, or do the work for the promotion you want,
and you'll earn the promotion, the same applies here. Show that the
secondary arch can function well as a primary arch without significant
burden to the rest of the project and then it's a much easier decision
to make the promotion.
> Speaking for myself, I see most of these
> things as a benefit of membership in PA rather than prerequisites. Or
> more to the point, transitioning from SA to PA means doing all of these
> things, so it's really just an order of operations that needs to be
> agreed upon.
"doing all of these things" doesn't happen magically just because the
board/fesco grants that ARM is suddenly a primary arch. If we made arm
a primary arch tomorrow, you'd still have to solve all the above issues,
only now you've got hundreds of very angry developers who's workflow is
now severely interrupted, and they're all calling for your head.
Doesn't it make more sense to solve these issues /before/ doing the
promotion? Figure out how to make the car go 60mph before taking it
onto the freeway, else you'll piss off all the other cars on the freeway.
>> That's set by you, as a secondary arch. Why not pin it to the Fedora
>> release schedule and see how well you do?
> We're quite close, though clearly the QE is different.
>> That said, within the websites group perhaps there is room for a
>> featured secondary arch, with high visibility. Having something to point
>> to first would help.
> Fair enough.
>> Did you just ignore the emails starting these two threads by mjg and
>> pjones? I believe they outlined some very good requirements for getting
>> a secondary arch into primary. These longer threads have been debating
>> some of the finer points of those proposals.
> On the contrary, mjg and pjones' emails are just the sort of
> constructive and thoughtful feedback I'm looking for. If the points
> they've raised (which they also raised yesterday) speak to everybody's
> concerns, then I'm happy to view them as the authoritative feedback of
> Fedora-devel for our planning purposes. On the other hand, if they've
> left anything out that should be considered in this plan, I'd like to
> see it.
Fair enough, I honestly didn't think you had ignored it, and it was rude
of me to suggest otherwise. I apologize for that.
"fedora-devel" doesn't really have anything of the "authoritative" sort,
we just have a lot of subscribers and opinions. Those opinions are
usually considered by FESCo when FESCo makes a decision, and generally
considered by those proposing something and asking for feedback on their
way to a FESCo decision.
Fedora -- Freedom² is a feature!
More information about the devel