On 03/20/2012 03:33 PM, Jesse Keating wrote:
> So in principle, do you object to the same koji hub being used
> 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
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.
"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
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
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.
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com