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

[Jim Keenan]

Peter,

Let me start from the end of your post first:

>= Rationale For Changes =
>
>Many of my commits in the previous week have been the result of an
>attempt to run Parrot on Minix/i386 with the amsterdam compiler kit
>(ack). As would be expected this led to the discovery of several
>faulty assumptions in Parrot.
>
>auto::timespec

[snip]

>
>auto::stat
>

[snip]

>
>auto::infnan
>

[snip]

If you had open Trac tickets for each of these additions and had developed them in a branch first, I would have had no quarrel with your approach.  I commend you for trying out Parrot on other OS/platform combinations and would like to see others emulate you in this regard.  You have considerable insight into many issues affecting Parrot, and other developers have spoken highly of your work.  It's only the process that you followed in this case that troubles me.

Now back to the middle of your post.

>
>While these guidelines seem like a good idea on paper, they may not be
>the best in practice.

Whether they're the best possible guidelines is not at issue here.  The fact of the matter is that they are *our current guidelines* and ought to be respected for that reason alone.  If you feel they are not appropriate, the remedy is: File a Trac ticket!

>
>List postings are subject to warnocking. Tickets even more so. 

That disparages the efforts the efforts of our cage cleaners.  We periodically go through old tickets and prod developers to get working on them.  In particular, as (FBOW) the de facto maintainer of the configuration system, I would have spotted any tickets you had filed re additional configuration steps and responded promptly to them.

>It is
>difficult recruiting testers for all core platforms (let alone
>best-effort platforms like Darwin/PPC). 

I don't see the relevance of that statement to the issues at hand.

>Svn branches are clunky, I've
>seen them fail to execute even a fast-forward merge without conflicts.
>

While many of our developers feel that Subversion branches which touch many source code files are ungainly during merging, any branches you would have created for adding configuration steps would only have touched a few files.  Parrot developers who have been around for 3 or more years know that in the past we created many branches to add/modify the configuration system and merged them in successfully.

Moreover, even when we transition to git, direct commits to 'master' (or whatever we'll call it) will not be a good development practice.

[snip]

>
>All this has caused me to tend towards a
>shoot-first-ask-questions-later approach for small changes. We're at
>the ask-questions part now. 

These changes may have been small in terms of the number of files they touched, but since they were made at the *start* of the Parrot configure-build-test-install chain, they are having considerable downstream impact.

More importantly, while "shoot-first-ask-questions-later" may be the standard development approach in other open source projects, and while it may even have been the standard approach in Parrot before, say, 2007, it is clearly *not* Parrot's current preferred development approach.  You will find that if you develop in a branch, then post requests for testing and comments, your fellow Parrot developers -- particularly the cage cleaners -- will respond quickly.  And if you open Trac tickets to track particular projects, other developers will be able to handily reference your discussion of the issues in the future.

>So if you feel these changes don't belong,
>you are more than welcome to revert them.
>

As whiteknight pointed out in his post to this thread, we have a supported release coming up next week.  My hunch is that we won't have enough time to thoroughly study and fix the inf_nan problems before then.  In particular, I won't have very much time to work on the Darwin problems until I arrive in the Pacific Northwest next week.  So we should consider reverting those changes.  But let's see what #parrotsketch today has to say about that.

In the meantime, would you be willing to retroactively open a Trac ticket for each of the three new config steps?

Thank you very much.

Jim Keenan (kid51)