You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I can tell, nobody is using GAP on Itanium and Sparc anymore, yet we have dedicated code for both of them in our source tree. The problem with that is that it prevents us from refactoring associated code, at least not without risking to break those systems.
Apparently, sparc64 support is already broken now: https://buildd.debian.org/status/logs.php?pkg=gap&arch=sparc64
I see these three options (for each of the two architectures separately):
Remove the code.
Leave the code in nominally, but stop worrying about breaking it.
Somebody volunteers to fix either arch, and regularly test it, and be available to help detect, debug and fix regressions (of course they wouldn't have to
I greatly dislike option 2, and don't see any actual advantage in it over option 1; it just gives a false outward impression ("look they have code supporting X in there!"). And if somebody ever wanted to restore support for either architecture, the old code would still be in the repository anyway.
Option 3 would be OK, but we'd really need outside help. We are not going to invest hours and hours of work into finding or setting up a test system (say, via qemu) for a hypothetical use case. I would reconsider this if there were dozens and dozens of users popping up; but I'd expect that one or more of them would volunteer for option 3. If that doesn't happen, perhaps they don't need the arch that strongly after all?
The text was updated successfully, but these errors were encountered:
We removed Itanium support, and decided to keep Sparc support in for now, as Bill Allombert expressed interest and is testing it inside Debian for Sparc.
As far as I can tell, nobody is using GAP on Itanium and Sparc anymore, yet we have dedicated code for both of them in our source tree. The problem with that is that it prevents us from refactoring associated code, at least not without risking to break those systems.
Apparently, sparc64 support is already broken now: https://buildd.debian.org/status/logs.php?pkg=gap&arch=sparc64
I see these three options (for each of the two architectures separately):
I greatly dislike option 2, and don't see any actual advantage in it over option 1; it just gives a false outward impression ("look they have code supporting X in there!"). And if somebody ever wanted to restore support for either architecture, the old code would still be in the repository anyway.
Option 3 would be OK, but we'd really need outside help. We are not going to invest hours and hours of work into finding or setting up a test system (say, via qemu) for a hypothetical use case. I would reconsider this if there were dozens and dozens of users popping up; but I'd expect that one or more of them would volunteer for option 3. If that doesn't happen, perhaps they don't need the arch that strongly after all?
The text was updated successfully, but these errors were encountered: