# New Ticket Created by James Keenan # Please include the string: [perl #53142] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53142 >
At particle's suggestion, about a year ago I began doing maintenance work in, and writing tests for, the Parrot configuration system. For much of this time, the system has been relatively stable. In the past 60 days, however, no fewer than 6 completely new steps have been added to the Parrot configuration process. auto::gettext (r26100 | particle | 2008-02-27) auto::crypto (r26359 | fperrad | 2008-03-14) auto::glibc (r26946 | particle | 2008-04-12) auto::opengl (r27022 | infinoid | 2008-04-18) gen::opengl (r27022 | infinoid | 2008-04-18) gen::digest (r27060 | fperrad | 2008-04-20) AFAICT, in none of these cases was there any advance notice that new steps were going to be added to the process. I just did 'svn up', and there they were! I would have expected RT [TODO] tickets to have been created for these additions, and I practiced that myself when I did extensive refactoring to, or renaming of, any previously existing config step. I would have been okay with that if I had a good idea as to the direction in which Parrot configuration was evolving or if these additions were in fulfillment of a previously documented plan -- but I didn't and they weren't. So, while I'm not disputing the merits of any one of these new configuration step classes (I like the spinning triangle you get with the opengl steps!), I am at a loss to answer questions such as these: * Is new configuration step X::X *necessary* for the functioning of the Parrot virtual machine? * If new step X::X is not necessary for Parrot, what makes it *desirable*? Why should it be included at the cost of increased complexity in configuration, build and testing? These lead to even bigger questions: * Why do we have all these configuration steps in the first place? Which ones are necessary for Parrot? And which ones are there simply because someone with a commit bit wanted that feature? * As we close in on Parrot 1.0, what "must-have" configuration steps, if any, are we lacking? And what others are people planning? I've had a few IRC conversations with particle and others about the direction Parrot configuration is taking, but those have mostly been concerned with how configuration might change after 1.0 -- not what has to happen between now and 1.0. And, of course, there's the cage-cleaner's perspective: Very few of these new config steps have applied cleanly or been tested adequately prior to commit. So there's been a lot of breakage, particularly along OS-lines. And I've had to either poke people to write tests or write them myself on a catch-up basis. I would like to propose both short-term and long-term remedies. Short-term: If you are proposing a new configuration step, or doing a significant overhaul of any existing step, please post an RT with the code and with a [TODO] tag several days ahead of time. This will give people a chance to run it on different OSes right away, without compromising trunk. And if I get advance notice of any new config step, I pledge to work with you to develop tests for that step. Long-term: We need a Parrot design document on configuration. Such a document should cover what configuration is, why we have decided to include the configuration steps already there, what we need and what we don't need. Such a document should distinguish between what we need between now and 1.0 OTOH and post-1.0 OTO. Thank you very much. kid51
