On Thu, Jul 11, 2013 at 04:01:15PM +0200, Miloslav Trmač wrote:
On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett
> That's the point. You don't get to be a primary architecture until
> you've demonstrated that doing so won't slow down the other
Is that "you don't get to be a primary architecture unless you have
demonstrated that nobody outside of the ARM SIG needs to do any work
on the architecture" == "you don't get to be a primary architecture
unless it doesn't matter whether you are a primary architecture"?
Promotion is supposed to benefit Fedora, not the architecture being
> and that requires you to fix all of these problems
> yourself first.
That's backwards. For the vast majority of Fedora packagers, ARM
becoming a primary architecture primarily means that every individual
package owner is supposed to fix their packages.
So promoting ARM comes at a cost to every individual package maintainer,
who now has to do additional work.
So, in some abstract ideal case, there would be a gradual transition
between an ARM SIG starting the bootstrap effort, and non-ARM package
owners gradually taking care of their packages on ARM as well, with
the experience and knowledge slowly spreading enough so that a switch
to primary when everyone is expected to care eventually becomes a
no-brainer, and the ARM SIG can significantly reduce its scope to
ARM-specific tooling changes.
I agree that that's the ideal case. If package maintainers are willing
to volunteer their time to ensure their packages work on ARM then
everything is easier and we all benefit. That doesn't seem to be the
What you are asking for is the exact opposite: that the ARM SIG
temporarily expands to "own" the ARM aspect of the whole distribution
until there are no ARM bugs, and then to have a "big bang" switchover
to a situation when everyone is supposed to handle their own package
What I'm saying is that making ARM a primary architecture isn't going to
automatically make volunteers start caring about ARM, and so there
should be evidence that the existing ARM porters can deal with the worst
case scenario of supporting an arbitrary set of packages themselves.
Matthew Garrett | mjg59(a)srcf.ucam.org