[Bug 453503] Review Request:zenon - Automated theorem prover for first-order classical logic
bugzilla at redhat.com
bugzilla at redhat.com
Wed Jul 9 04:10:56 UTC 2008
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request:zenon - Automated theorem prover for first-order classical logic
https://bugzilla.redhat.com/show_bug.cgi?id=453503
------- Additional Comments From dwheeler at dwheeler.com 2008-07-09 00:10 EST -------
Thanks for the review! Regarding questions/recommendations:
* I think the rpmlint result for the bytecode-only-version should be ignored.
The problem is that rpmlint lacks context. rpmlint can't realize that you
would normally run a machine code version, and that the only reason that
there's a bytecode version is because nothing better is available for
that particular architecture.
* "perhaps should be attempted for f10." Ok, good point. I built for f10 using:
koji build --scratch dist-f10 ../SRPMS/zenon-0.5.0-1.fc9.src.rpm
and got 5 clean builds (no failures).
* "I would move tptp-COM003+2.p out of %doc - it's not really a
documentation file, it's a data (non-binary) file that probably
just belongs in %{_datadir}." Hmm, I'm not sure how to respond to that.
The reason I put it in %doc was because I was thinking of this test case
as an example. It enables a human to understand (through example) how to
use the program. It's _not_ used during run-time (normally), e.g., it's
not an architecture-independent library or anything like that.
And this program has squat for documentation, so even an example
is more than it had otherwise :-).
I'd prefer to leave it in %doc, primarily because there's so little
documentation that I'd rather give them SOMETHING to start.
But I'm not hard over it. Anyone else have any thoughts?
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
More information about the Fedora-package-review
mailing list