On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer <fweimer@redhat.com> wrote:

On 06/04/2018 05:55 PM, Jeff Backus wrote:

Would you please provide more detail on what problem or problems we are trying to solve? Is this purely for efficiency reasons?

Mainly developer efficiency. There will be fewer test suite problems due to excess precision (a bunch of packages carry patches which introduce -ffloat-store on i686 to work around them). Packagers will not have to figure out a way how to build for compatibility with non-SSE2 systems (which some upstreams do not support anymore).

Furthermore, the divergence from downstream is troubling to Red Hatters for various reasons. (Red Hat Enterprise Linux 7 already underwent a similar change.)

Thanks for the insight. Yes, I can see the advantages. However, have things really gotten so bad that it justifies ejecting part of the community? Yes, a minor part of the community, but a part of the community none the less. As you mentioned, the excess precision issue has a known work around. And for packages where upstream does not support non-SSE2, packagers can raise a flag with the x86 SIG. If there isn't enough interest or bandwidth to add support for non-SSE2 systems, then I think it is perfectly reasonable to add a note in the package description and move on. I believe packages such as Dark Table already do this?

Until (unless?) we have data indicating that this is a major drain on community resources, I'd push back on a change that actively excludes part of the community. Now, if we do have data indicating that supporting non-SSE2 systems with the i686 architecture is a not-insignificant burden on the community, then I ask that this proposal be updated to include a solution that allows us to not push out part of the community, e.g. Ajax's i586 suggestion.

Not trying to be quarrelsome. I understand the desire to focus efforts, however, I hope we can also appreciate the concerns of those of us with currently supported hardware that would be affected by this proposal.

jeff

Jeff Backus
jeff.backus@gmail.com
http://github.com/jsbackus