Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=520505 --- Comment #10 from Chris Weyl <cweyl@xxxxxxxxxxxxxxx> 2009-09-05 16:36:45 EDT --- (In reply to comment #8) > As said, it's been discussed before. So, again, do you have any real examples of "actual harm" specific to including the tests as documentation, or is this all handwaving and FUD? If I remember correctly, there weren't any real examples the last time this came up, either... And if I'm being accused of causing Fedora "actual harm", I'd at least like to see the evidence against me. Dependency bloat (from %_docdir contents) is a long standing rpm issue that no one seems willing to tackle; by policy we don't allow deps in %_docdir so Fedora rpm shouldn't even look in there. And frankly, I don't think it's unreasonable to say that I've done more recently to help eliminate %_docdir and other spurious deps by writing up and proposing the filtering system now in place than any other effort I've recently seen. (Corrections welcome.) If rpm conformed to Fedora policy, %_docdir deps wouldn't ever be an issue with any package. Catalyst test suites often contain mini test-apps that help demonstrate how something actually works. MooseX::AttributeHelpers was for ages poorly documented; the tests were the only real way to help figure out how they worked. MooseX::Workers sounded really quite cool didn't make any sense until I read through the test cases. If one does a basic google search[1] for 'site:search.cpan.org AND ("see the test suite" OR "see the tests")': MP3::M3U::Parser ("See the tests in the distribution for example codes"), Parallel::Forker ("For more examples, see the tests"), MooseX::Types ("See the tests directory for a start on this", w.r.t. a specific coding scenario), WWW::Netflix::API ("Also see the "TEST SUITE" source code for more examples"), etc, etc. As to "undocumented api"... We all know the conventions, we all get to make our own decisions, and we all know we're shooting ourselves in the foot (or head) if we use internal methods. If this were a real argument, we should probably not allow any users to see the source code at all. Or have root. Or a keyboard. :) I think the ability to run the test suite post-install is pretty important, but we're installing them in %_docdir. ATM the intention is to have them as documentation; if someone uses them beyond that that's their own doing. And I hardly think running a test suite "post-install" is a "bad practice"; modern Perl apps often have a fairly extensive dependency tree... It's nice to be able to validate that updating perl-Sub-Name, say, isn't going to somehow break Class::MOP and thereby your Catalyst app. Unless we start breaking them out into -tests subpackages, we don't need to consider this here, however, as they stand quite nicely on their own as docs. Soo... maybe the "undocumented" / "bad API" theories held some weight back in 1999, but this is 2009. Modern Perl test suites are an entirely different animal. I'm more than open to reconsidering the merits of this, but I haven't seen any of the "actual harm" claimed to be specific to including the tests in %_docdir. [1] http://www.google.com/#hl=en&q=site%3Asearch.cpan.org+AND+("see+the+test+suite"+OR+"see+the+tests")&aq=f&aqi=&oq=&fp=3aa7f458acaa2672 -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
