Fellow Parrot developes,
In its discussion of adding new components to the Parrot configuration
process, docs/configuration.pod contains this language:
"It is strongly recommended that you file a Trac ticket in which you
state the rationale for adding a new configuration step and sketch
out what the code in the step would look like."
We included this language in November 2009 to guarantee that developers
who sought changes in the process would:
* present their rationale for the changes to other Parrot developers;
* provide an opportunity for other developers to review the code, both
at the level of individual statements and at the level of assessing the
rationale for the changes;
* allow thorough testing of the code -- typically, in a branch -- on all
our supported operating systems prior to committing the code to trunk.
As one who has been involved with maintaining Parrot's configuration
system for over three years, I strongly believe that these procedures
should be followed. Unfortunately, three new configuration steps have
been added in the past week, none of which have had Trac tickets opened
for them and none of which were developed in branches prior to
commitment to trunk. These new steps are:
Sep 29 17:12 config/auto/timespec.pm
Oct 2 18:45 config/auto/stat.pm
Oct 2 23:14 config/auto/infnan.pm
The only rationale we have for these new config steps is that presented
in their commit messages. I haven't had time to assess fully the
purpose or impact of auto::timespec or auto::stat -- or to write t/step/
tests for them -- but we are having a lot of problems with auto::infnan;
see TT #1813; TT #1814; and TT #1815. I recognize that the developer
who added these steps is working to resolve the problems -- but we
should be facing these problems in a branch, not in trunk.
I want to stress that the configuration system is not written in stone.
There may be a strong case for additional configuration steps -- but
we should hear that case before such steps are added. Furthermore, we
know that we have to figure out a way to reduce and ultimately eliminate
our dependence on Perl 5 %Config in init::defaults and auto::headers.
If you think about it, the recommendations in the docs for best
practices in creating configuration steps really applies to all our code
base. We know that there are vast areas in our code base in need of
improvement. We know that in many areas different approaches will be
needed. We want developers to be able to plunge in and get to work.
But when a developer's proposed changes to the code base affects Parrot
as a whole, we need to have the code and the rationale for the code
presented and developed in an orderly manner. The presentation takes
place in Trac (perhaps supplemented by posts to this list); the
development should take place in a branch.
Thank you very much.
Jim Keenan (kid51)
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
