On Thu, Apr 10, 2008 at 11:23 AM, Larry Wall <[EMAIL PROTECTED]> wrote:
>  On a larger question, I'm wondering if it's time to slush/freeze
>  the Synopses as historical documents and put all spec effort into
>  the new form (presumably as a wiki that knows how to serialize into
>  a document).  I don't think we have the bandwidth to maintain multiple
>  standard documents.  Well, okay, *I* don't have the bandwidth...
from the perspective of a language implementor, i believe that
formalization may be a benefit in the long term. however, it will
cause some short-term disruption with which i'd greatly appreciate

specifically, the spec test suite employs the use of smartlinks, which
are pod-like tags used to relate a set of tests to specific locations
in the synopses. modification of the spec format will require
modification of the spec test suite, and the coverage/reporting tools
(e.g. smartlinks.pl.) also, modification of the spec file type from
.pod to .odf will certainly add to the complexity of any tool
migration. as multiple implementations of the spec are now maturing,
these tools have become more important to judging the progress of any

also, as manager for the parrot and perl 6 projects under the perl
foundation umbrella for google summer of code (GSoC), i'd like to note
that there's a chance we'll have a student working on a project to
improve the perl 6 test suite. i expect this student to make good use
of today's existing tools, like smartlinks.pl, in the course of his
project. reformatting the spec documents will likely implement this
effort, and may lead to a failed project where the student will not be
compensated. i certainly don't want to see that happen. i'll know more
about whether or not this project has been accepted in the coming

i hope that the hackathons during the upcoming conference season will
be a place where folks can help us improve the spec test suite, and
that a spec document format change today will be disruptive. i'd love
to see folks helping out with migration to a new documentation format,
as well, but i think it's easier if we keep the current documents
up-to-date until the migration is considered complete.

i believe that if we put effort into migrating to a new format, while
keeping the current spec pod format as canon, and later (post-GSoC)
marking the current spec documents as historical, it will allow time
for implementation, documentation, and testing projects to move
forward during the traditionally busy summer months.


Reply via email to