Reminder about adding new configuration steps (and other potentially significant code)
Andrew Whitworth
wknight8111 at gmail.com
Tue Oct 5 12:44:26 UTC 2010
I have to agree with Jim on this one. I don't know a whole lot about
these new configure steps or the reasons why they were implemented.
However, what I do know is that the configuration system is the very
first thing that a potential new Parrot developer will interact with
when trying to build Parrot. If Configure.pl is broken (and it's a
non-trivial system) the developer won't even have a makefile around to
play with, much less any hope of getting things working.
I don't have any real input on the process other than to say that if
it's written in the docs that it be done a certain way, and if Jim
(the lead developer on the tool until this point) says it should be
done a certain way, that sounds to me like the way to do it for now.
How difficult would it be to rip those new configure steps (and any
other code that's dependent on those steps) out of trunk and into a
branch or branches? I know it's been a little while since they went
in, but trunk has been pretty quiet for the last few days so it might
not be a huge undertaking.
We have a release coming up in two weeks. We certainly need trunk as
clean and stable as possible by that point. If these configure steps
absolutely should not be part of trunk if they are not stable by that
point.
Thanks,
--Andrew Whitworth
On Tue, Oct 5, 2010 at 8:30 AM, James E Keenan <jkeen at verizon.net> wrote:
> 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
>
More information about the parrot-dev
mailing list