https://bugzilla.redhat.com/show_bug.cgi?id=912960 Toshio Ernie Kuratomi <a.badger@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|package-review@lists.fedora | |project.org | --- Comment #34 from Toshio Ernie Kuratomi <a.badger@xxxxxxxxx> --- Few comments: About the definition of hiding: The patch doesn't hide the test failure. It attempts to fix the test failure. Hiding it would be to comment out that test or disabling the test suite. About verifying with upstream: The rationale for not applying the patches is that you're not able to evaluate whether the patches to the test case are correct and that's worrisome enough that you won't apply a proposed fix for it because it might break the package more. However, that means that the package you are building could be severely broken. Severely broken packages aren't supposed to pass review. So enough review of the issue needs to take place so that we know whether the issue is one that compromises the operation of the package. But once someone does that it becomes apparent whether the patch is okay to apply or not: if the issue is really serious, the patch to the test case is incorrect and the package should not be approved until the actual issue is fixed. If the issue is minor, the proposed fix to the test case is something that can be applied and the problem and proposed solution sent upstream. It can be changed if upstream's evaluation turns out to be different. There's two places where our expectations might not match up here. The first would be that we have different implicit rankings of solutions to test failure. Here's mine from most desirable to least desirable: 1) Fix the bug the right way. 2) Potentially fix the bug the right way (unsure enough to need further evaluation) 3) Fix the bug in a way that you know is too hacky for upstream but fixes the problem on Fedora 4) Disable the specific case that's provoking the issue. 5) Disable the entire test suite. The second place where our thoughts might mismatch is in the definition of "disable". For me, a disabled test or test suite is one that does not fail the build if the test or test suite doesn't pass. I think that your definition is slightly different; I'm guessing you'd say that not running the test at all is what constitutes disabling. The reasons I'd give for my view are: * On rawhide if the build succeeds the new build will replace the old package no matter what the test suite printed to the logs. * When someone else rebuilds the package for some reason (releng rebuild, provenpackagers rebuilding for changes to guidelines Fedora Change Owner rebuilding dependent packages), they won't know that they have to look at the build log of this package to see the test suite results. Even if they do, they won't know what the old baseline was, only what the current results are. * If you should give up maintaining the package and someone else take over (maybe just to satisfy the deps in their own package) they won't know that a failing test suite will not fail the build. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=2wuOck1Ifu&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review