On Mon Apr 21 16:21:18 2008, geoff wrote: > > As a non-core contributor, my impression is that there is no top-down > plan. Parrot's development appears very much guided by dynamic tension > between the real bottom-up work, docs ranging from prescriptive to > descriptive to imaginative, and a *desire* to have a top-down plan. > Personally, I think this dynamic tension is healthy, and trying to limit > one facet in deference to the others seems counterproductive. >
I'm mostly in agreement. It just seems to me that the configuration ought to be settling down as we near 1.0. > [snip] But see the next question. > > > * If new step X::X is not necessary for Parrot, what makes it > > *desirable*? > > [snip] > Thus I'm in favor of including what I see as basic cross-language > bindings for a number of cross-platform libraries -- crypto, database, > 2D graphics, 3D graphics, email, common network protocols, compression, > and so on. > > But let me take the opposing view for the moment that we *don't* want to > include such libraries for Parrot 1.0. Parrot is finally reaching the > point where creating such libraries is not only possible, but reasonable > without worrying that all of the code will have to be rewritten multiple > times before we get to 1.0. It seems inevitable that people will > scratch their own itches and start to develop such libraries -- this is > borne out by the very existence of the config steps you mention. > > These libraries need some forum for being tested on different platforms, > bugs worked through, and so on. In addition, there is still enough > churn in PIR and Parrot itself that it is desirable to make sure that > global design changes are propagated to these libraries as well. Right > now there is no good place for this other than the Parrot codebase > itself. Even if we decide to split out libraries from the Parrot core > for the Parrot 1.0 release, I'd argue that for now we need to continue > to incubate the nascent libraries inside Parrot until a truly viable > replacement can be created. > Very good points -- on both sides of the issue! > > > 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. > > Why is RT[TODO] better than RT[NEW], which according to submissions.pod > is the proper way to submit a new feature? (And the way that I > submitted my patch, once I learned about that.) > As mentioned in another post, what I'm really hoping for is an RT like the one you submitted -- regardless of tag. > > 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. > > This would be a very good idea. I was stumbling through with cargo > culting and guesstimation. I would rather have just been able to read a > good doc. > Thank you very much. This multiplies by 3 or 4 the amount of discussion we've had on list about these issues.
