----- 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_Bugs > > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
