RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 03:33 PM, Jesse Keating wrote:
>> 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.

Context for the question: One of the benefits to PA that I see is that 
PA's infrastructure is really good.  I mean, the reliability is 
outstanding.  Kudos to all involved.  To what extent can a secondary 
sharing in that bliss?  Machines in the same racks? Services on the same 
machines?  The same koji hub, but treating failed SA builds differently 
than failed PA builds?  How close can we get to treating a secondary 
architecture like a primary, as far as that infrastructure goes?  Is the 
limit, again, as close as we want up to the point of it affecting 
primary programmatically?   Or should there be a separation, even if 
it's technically feasible to combine the services for both SA and PA?

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

Agreed.  We definitely want promotion, in the end, to be a small ripple, 
if little notice because the hard parts are already done.

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

Yes...

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

Absolutely.  We're having this discussion as a way to solve the issues 
before promotion.  None of us expect ARM to be promoted today, or 
tomorrow, but perhaps 3-5 months from now is realistic.  Or maybe that's 
too soon.  The bottom line is that there are issues to be worked out and 
that's what has prompted the discussion.

> Fair enough, I honestly didn't think you had ignored it, and it was rude
> of me to suggest otherwise. I apologize for that.

Thanks-  I didn't think your replies mean spirited and very much 
appreciate your taking the time to think about the issues with the 
proposal.  It's a work in progress and it will certainly be a while 
before it's complete enough that to be approved.  We're charting a 
course toward primary and these threads are simply a way of drawing up 
the map we'll be taking.

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

Yep.  Regards,

-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com