Reminder about adding new configuration steps (and other potentially significant code)

[James E Keenan]

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)