F<AUTHORS> file, which ships in the official distribution. How many other
programming languages offer you 1 line of immortality?
+=head1 The roadmap to 5.10
+The roadmap to 5.10 envisages feature based releases, as various items in this
+TODO are completed.
+
+=head2 Needed for a 5.9.3 release
+
+=over
+
+=item *
+Implement L</lexical pragmas>
+
+=back
+
+=head2 Needed for a 5.9.4 release
+
+=over
+
+=item *
+Review assertions. Review syntax to combine assertions. Can assertions take
+advantage of the lexical pragams work? L</What hooks would assertions need?>
+
+=back
+
+=head2 Needed for a 5.9.5 release
+
+=over
+
+=item *
+Implement L</_ prototype character>
+
+=item *
+Implement L</state variables>
+
+=back
+
+=head2 Needed for a 5.9.6 release
+
+Stabilisation. If all goes well, this will be the equivalent of a 5.10-beta.
=head1 Tasks that only need Perl knowledge
errors. See also L</make HTML install work>, as the layout of installation tree
is needed to improve the cross-linking.
+The addition of C<Pod::Simple> and its related modules may make this task
+easier to complete.
+
+=head2 Parallel testing
+
+The core regression test suite is getting ever more comprehensive, which has
+the side effect that it takes longer to run. This isn't so good. Investigate
+whether it would be feasible to give the harness script the B<option> of
+running sets of tests in parallel. This would be useful for tests in
+F<t/op/*.t> and F<t/uni/*.t> and maybe some sets of tests in F<lib/>.
+
+Questions to answer
+
+=over 4
+
+=item 1
+
+How does screen layout work when you're running more than one test?
+
+=item 2
+
+How does the caller of test specify how many tests to run in parallel?
+
+=item 3
+
+How do setup/teardown tests identify themselves?
+
+=back
+
+Pugs already does parallel testing - can their approach be re-used?
+
=head2 Make Schwern poorer
We should have for everything. When all the core's modules are tested,
various times worked to cut it down. There is probably still fat to cut out -
for example POSIX passes Exporter some very memory hungry data structures.
-=head2 Refactor C<xsubpp> to be a thin wrapper around C<ExtUtils::ParseXS>
-
-C<ExtUtils::ParseXS> encapsulates a version of the C<xsubpp> into a module.
-In effect this is a code fork, and it's likely that C<xsubpp> has had some
-bug fixes since the code from C<ExtUtils::ParseXS> was derived. It would be
-good to merge the differences in, reduce down to 1 canonical implementation,
-and convert C<xsubpp> to a very thin command line wrapper to
-C<ExtUtils::ParseXS>.
-
-In theory this needs no real C knowledge, as one way of approaching this task
-is to ensure that C<ExtUtils::ParseXS> generates identical output to C<xsubpp>
-for input XS files, which does not require understanding the contents of the
-output C file. However, some C knowledge is likely to help with testing, and
-locating/producing comprehensive test cases.
Study the possibility of adding a new prototype character, C<_>, meaning
"this argument defaults to $_".
+=head2 state variables
+
+C<my $foo if 0;> is deprecated, and should be replaced with
+C<state $x = "initial value\n";> the syntax from Perl 6.
+
=head2 @INC source filter to Filter::Simple
The second return value from a sub in @INC can be a source filter. This isn't
=head2 make ithreads more robust
-Generally make ithreads more robust. See also L<iCOW>
+Generally make ithreads more robust. See also L</iCOW>
This task is incremental - even a little bit of work on it will help, and
will be greatly appreciated.