Patrick R. Michaud wrote:
I don't think it's practical (or necessary) to run the HLL tests for every commit to Parrot. But I do think it's important that we test Parrot against a standard set of HLLs prior to a major release (substitute your desired value of "major" here), if only to make sure that the about-to-be-released-major-Parrot isn't the source of any huge blockers for the HLLs.
Agreed that we need to synchronize testing on HLLs for releases. Especially the January/July releases, but every release would benefit from it.
I've gone ahead and created TT #399 for this, as well as placed it as a "critical" item on the ParrotRoadmap page, so that this isn't overlooked or forgotten at the time of the release.
Thanks.
I might also suggest we add the step to the release_manager_guide.pod document.
From branch merging, the tricky part has always been knowing how to interpret language failures. (Are they known and expected in the language? How to figure out if they're caused by something in Parrot core, tracking down the cause in an unfamiliar codebase?) And now we add to that since most languages aren't tracking trunk, and so might not run on trunk without modification (e.g. to test one language against trunk recently, I ended up submitting a patch to update Parrot API function names).
So, rather than adding "run the tests for X HLLs" to the release process, I'd like to add "check with Y HLL project leads for any release blockers" a couple of weeks in advance of the release. It puts the testing burden back on the language developers, but also makes sure we verify the languages before making the release. Sound workable?
Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
