On Sun, 2008-04-20 at 19:01 -0700, James Keenan wrote: > 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.
Two of these are from me (auto::opengl and gen::opengl). I had attempted to discuss OpenGL bindings on p-p and in IRC multiple times in the past; in each case the discussion either veered off into technical details or was Warnocked. No, I didn't create an RT [TODO] ticket, because I didn't know that was required. However, it seems redundant with both A) previous discussions, and B) discussion that occured on the RT [NEW] ticket I did open for my feature patch. > 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. 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. > 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!) Thank you! > 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? For at least the OpenGL steps, and likely some of the others, the answer is clearly no. But see the next question. > * If new step X::X is not necessary for Parrot, what makes it > *desirable*? For me personally, a vast attraction of Parrot as a VM is the ability to provide common libraries for common functions that can be used across many languages. Commonly this is discussed in terms of "Python can use CPAN", but I don't see any reason why we shouldn't take this as an opportunity to merge some of the best stuff from each different language's modules and make something better from the fusion, and include it out of the box. 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. > Why should it be included at the cost of increased > complexity in configuration, build and testing? I don't think that argues for not including features/libraries/what have you. That argues for making config/build/test clean, easy, and fast. > 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 I mentioned above, probably most of these are not *necessary*. However, I think at least some of those with commit bits believe they are a good idea -- I don't have a commitbit, so multiple commit holders helped me with getting this accepted and working cross-platform. > 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. On my part, this was intentional. I specifically waited a day or two after the monthly release before asking for my patch to be committed, knowing there would be breakage. In fact, one of the big reasons I wanted to get my code into the main tree was to shake out these portability problems -- both as an end of its own, and so that I could better understand how to approach portability for Parrot libraries; very few examples/docs existed to guide me. > And I've had to either poke people to write tests or > write them myself on a catch-up basis. That's a separate issue, that I will be discussing in chromatic's thread on config tests. > 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.) > 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. Ditto! -'f
