Re: RFC: Primary architecture promotion requirements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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.

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux