Currently, for arch-only issues which don't have an upstream fix our approach is to solve them at a packaging level by disabling some part, be it tests, functionality, dependencies, etc.
Unless we keep track of these kind of changes, we will only come across them again when a runtime error and/or an issue in another package using the faulty one arises.
So the same way we have tracker tickets for arch-specific bugs, I think it would be a good idea to have tracker ticket(s) for %ifarch workarounds. Having all these issues aggregated in one place makes it easier to check them from time to time if they are still valid/relevant or if there is a fix upstream for them.
Note that we could only leave the original bug reports open. Besides losing the aggregation part from my proposed solution, and even if there are specific comments in there indicating the workaround, one would have to go through the entire history to understand why that issue is still open.
Att -- Rafael Fonseca
----- Original Message -----
Currently, for arch-only issues which don't have an upstream fix our approach is to solve them at a packaging level by disabling some part, be it tests, functionality, dependencies, etc.
Unless we keep track of these kind of changes, we will only come across them again when a runtime error and/or an issue in another package using the faulty one arises.
Here is one example of the kind of problems I'm talking about https://bugzilla.redhat.com/show_bug.cgi?id=1162738
Att -- Rafael Fonseca
On Fri, Aug 14, 2015 at 04:56:15AM -0400, Rafael dos Santos wrote:
----- Original Message -----
Currently, for arch-only issues which don't have an upstream fix our approach is to solve them at a packaging level by disabling some part, be it tests, functionality, dependencies, etc. Unless we keep track of these kind of changes, we will only come across them again when a runtime error and/or an issue in another package using the faulty one arises.
I'm a little confused about exactly what you're asking for.
The obvious solution is to create a tracker bug, and to make the other bugs block the tracker bug. See for example:
https://fedoraproject.org/wiki/Architectures/ARM/Package_Maintainers#Tracker...
https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker
But ...
Here is one example of the kind of problems I'm talking about https://bugzilla.redhat.com/show_bug.cgi?id=1162738
... I see there is already a tracker bug associated with this bug. If you need to track some other issue different from what PPC64LETracker is tracking, then I guess create another tracker bug for that issue.
Rich.
----- Original Message -----
On Fri, Aug 14, 2015 at 04:56:15AM -0400, Rafael dos Santos wrote:
----- Original Message -----
Currently, for arch-only issues which don't have an upstream fix our approach is to solve them at a packaging level by disabling some part, be it tests, functionality, dependencies, etc. Unless we keep track of these kind of changes, we will only come across them again when a runtime error and/or an issue in another package using the faulty one arises.
I'm a little confused about exactly what you're asking for.
The obvious solution is to create a tracker bug, and to make the other bugs block the tracker bug. See for example:
https://fedoraproject.org/wiki/Architectures/ARM/Package_Maintainers#Tracker...
https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker
But ...
Here is one example of the kind of problems I'm talking about https://bugzilla.redhat.com/show_bug.cgi?id=1162738
... I see there is already a tracker bug associated with this bug. If you need to track some other issue different from what PPC64LETracker is tracking, then I guess create another tracker bug for that issue.
Yes, my idea is to create tracker bug(s) for cases when we disable tests/functionality for a specific architecture.
So for example the pixman's case. The tests were disabled, so the build always succeeded. If the build always succeeds, who's going to check that the tests are actually disabled for that platform? If these kind of changes were tracked, it would be easier to go through then and check whether the issue was fixed and the tests/functionality can be enabled again.
The other alternative (which happened with pixman) is to leave the original bug report open. But then someone has to go through all the open issues and read the entire history to find out if they are just unresolved bugs or "records" for future consideration.
Att -- Rafael Fonseca