https://bugzilla.redhat.com/show_bug.cgi?id=912960 --- Comment #41 from Toshio Ernie Kuratomi <a.badger@xxxxxxxxx> --- (In reply to Mamoru TASAKA from comment #37) > It seems that on f20 i686 test fails (sometimes??) On f20 koji it failed with an error that I attribute to a change in API that this package depends on. That's the first patch in my email. After fixing that, I didn't retry the build multiple times to see if the .to_str() failure was only occurring sometimes but I can confirm that it happened on x86 f20 but passed on x86_64: http://koji.fedoraproject.org/koji/taskinfo?taskID=5899933 (In reply to Mamoru TASAKA from comment #39) > (Maybe some rounding effect is happening on ruby inside, however I am not > sure) <nod> Isn't the rule of thumb: Never depend on C code to precisely represent any floating point numbers? ;-) (In reply to Mamoru TASAKA from comment #38) > I won't say that reviews must not say anything which is not written in review > guidelines, however reviewers must be careful not to insist on making > submitters apply reviewrs' policy or faith. In so far as style goes I would agree with this. (For instance, trailing periods in Summary, removing shebang lines in importable code modules that trigger rpmlint but don't affect the code...) However, at some point undocumented points do make a technical difference. The testsuite is one of those places. If there's disagreement here, the reviewer could choose to try to make it a blocker (the most common route for this is to propose to the FPC that they add a rule covering it to the guidelines). Or the reviewer could consider that they consider it enough of a problem that they won't approve the package themselves but they understand that there's a difference of opinion and will let someone else pick up the review and finish it if they choose. I hope that explains that I don't consider that msuchy or anyone else has an obligation to approve the package without a commitment not to disable (sorry, my definition of disable) the testsuite. But at the same time, it's not currently something that all reviewers might consider a blocker. >From the Preamble of the Packaging Guidelines: "It is the reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.)" The reviewer has pointed out a shortcoming of the package. The two of you disagree on the severity. One of you could take this to FPC to make a definitive ruling or the two of you could decide to let another reviewer decide if they would like to approve this despite the problem. -- 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=rFpukLGHqs&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review