On Fri, Mar 30, 2007 at 08:58:19AM -0700, Allison Randal wrote: > I concur that the user shouldn't get failing tests for things like > whitespace at the end of lines. More importantly, the user shouldn't be > wasting time running tests for coding standards and documentation. How > about a 'make devtest' target that runs standards/doc tests first, and > then the ordinary 'make test' target? > > It would require all developers to get into the habit of running 'make > devtest' instead of 'make test', but that's not a heavy burden.
An alternative is to have C<make test> be an alias, either to C<make devtest> by default, and a smaller C<make usertest> (or somesuch) when the source tree is an official release. Having the source tree know when it's an official release (perhaps by including or not including a file) would also allow the parrot executable to report accurately whether it's the official release, or one patched in some local way. We've not figured out a good way to do this for Perl 5 yet. For Perl I'd really like it if even perl -v (the short version output) said "I'm patched somewhere", so that it was almost impossible to submit a bug report without that piece of information being forthcoming. (You don't need to know what the patches are immediately, because at least you now have enough information to ask the bug reporter to run perl -V or the equivalent, to actually find the information out) I assume that in the position of maintaining Parrot I'd like the same information about whether the release is vanilla and unmolested when I got a bug report. Nicholas Clark