> In closing, let me reiterate this point so it is crystal clear. If you are a maintainer of a libre software project and you refuse a community port to another architecture, you are doing a huge disservice to your community and to your software’s overall quality. As the Linux kernel has demonstrated, you can accept new ports, and deprecate old ports, as community demands and interest waxes and wanes.

Every feature has a cost and port to a different architecture has a huge cost in ongoing maintenance and testing.

This is open source. The maintainer isn’t refusing a port. The maintainer is refusing to accept being a maintainer for that port.

A person is always free to fork the open source project and maintain the port themselves as a fork.

▲

nine_k a day ago | parent [-]

Hmm, if the author of the port cares, why won't the author of the port become a maintainer of that port? This should be a two-way street.

▲

CJefferson a day ago | parent [-]

In my experience, as someone who has gone through this as maintainer of two decent sized projects, that simply doesn't work.

The author of the 'port' probably doesn't know your whole codebase like you, so they are going to need help to get their code polished and merged.

For endian issues, the bugs are often subtle and can occur in strange places (it's hard to grep for 'someone somewhere made an endian assumption'), so you often get dragged into debugging.

Now let's imagine we get everything working, CI set up, I make a PR which breaks the big-endian build. My options are:

1) Start fixing endian bugs myself -- I have other stuff to do!

2) Wait for my 'endian maintainer' to find and fix the bug -- might take weeks, they have other stuff to do!

3) Just disable the endian tests in CI, eventually someone will come complain, maybe a debian packager.

At the end of the day I have finite hours on this earth, and there are just so few big endian users -- I often think there are more packagers who want to make software work on their machine in a kind of 'pokemon-style gotta catch em all', than actual users.

	▲	awilfox 4 hours ago \| parent [-]
		There are many, many users for every one of us packagers. We (at least the four I am aware of, including myself) are not doing 'gotta catch em all', we're doing "we have been notified by users that this package (is not\|no longer) working". And it looks like 'gotta catch em all', because there are so many users, still. There are new users asking how to get Raspberry Pis into aarch64be mode in the Gentoo Arm project channels. There are thousands and thousands of Power Macs. SPARC servers with ridiculous amounts of cores and computer power are super cheap on eBay because Oracle ended support for them - and this is a great way to get a huge thread count cheap, if your software actually runs on it. Make the BE CI optional if you need to. That way, the maintainer has time to find and fix it, and you can still merge other changes while it runs. What binutils did was have the BE CI run separately and specifically ping the BE maintainers - that way, they know the build's failing, and no one else is bothered with it.