On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:
> In this case however I don't think much productive came from this
> discussion we had about hfsplus-tools. Obviously no one wants
> hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
> to fix it. So I think we should just drop it on ARM, and let anyone
> who wants it, fix it later (or reenable %{arm} if clang gets fixed).
Let me try this again. The aim is for Fedora to provide an experience
that's consistent across primary architectures to the extent that is
reasonably possible. If people don't care about that, we have a problem.
The nature of that problem depends on who is failing to do the caring:
1) If the ARM maintainers don't care about ARM being equivalent to x86,
that's a serious problem that is (with luck) easily fixable. On the
other hand, if they care but don't have sufficient resources to fix
things, that's a smaller problem but probably less easily fixed,
because:
2) If individual package maintainers don't care about ARM, there's
really not a lot we can do. They weren't involved in the decision to
make ARM primary. They probably don't plan on installing Fedora on any
ARM systems, so they gain no personal benefit from fixing it. What kind
of incentives can we provide? Threaten to drop their packages? That
would provide consistency, but it ends up being a rather limiting
strategy.
Honestly the most practical solution would seem to be a concerted effort
from the ARM team to fix these up - the assumption that individual
package maintainers will take care of things isn't realistic. But given
that they're busy getting arm64 into a good state, I don't know how
reasonable that is given the available resources.
I think there's a real problem if ARM continues to languish behind x86's
feature set, and I think it's realistic to ask whether that problem is
sufficiently serious for demoting it. But that's clearly not the most
desirable outcome, and so I'd really prefer us to figure out a way to
fix things. Improving code portability benefits us, our users and the
ecosystem as a whole.
--
Matthew Garrett | mjg59@xxxxxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
