On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer <fwei...@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.bac...@gmail.com http://github.com/jsbackus
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3K3SWOKJHZNRIVYN2WWASDSLVBZLQCBJ/
