On Mon, 2008-04-21 at 17:02 -0700, Mark Glines wrote: > 1. It seemed more relevant than some stuff that's already in > parrot. (I have more machines with OpenGL installed than have > postgresql, for example.)
Ditto, but of course, I'm biased. :-) > 2. The author (Geoff) was responsive, willing and able to fix issues as > they arose. Thus, if someone had a problem, we also had someone > motivated to fix it. Very much so. I figured if I wasn't responsive, my patch had no hope. > 3. We didn't have a release pending, thus we are not in feature freeze. As I mentioned in another message, this timing was intentional on my part. > And we also need a document defining what steps an implementer should > follow when adding or modifying configuration steps. You are right, the > process for OpenGL was a bit rocky, but in my defense, "I didn't know > any better". Actually, I don't really know much at all about the > config system, or the testing thereof. Ditto that. And for someone who is also trying to learn the ins and outs of Parrot itself, this was a significant part of the challenge to creating an acceptable patch. I finally had to say "I expect breakage, so best to choose my timing well, tell people I expect failures, and respond to bug reports as fast as possible." > docs/configuration.pod doesn't > seem to mention tests at all. Maybe if it did, then the next time > someone like me comes along and breaks everything, then you'll have > something to whack them over the head with. This seems a bit harsh. It's been some years since I followed Linux kernel development, but as I recall there used to be a 1-2 week period after each point release when new and possibly risky stuff was allowed to go in, knowing that there would be time to deal with the issues before the next freeze. Since we have fixed monthly release cycles, I propose the same for Parrot -- the week following each release, the barriers to entry for risky patches should be lowered somewhat. At the very least, this would allow new contributors like myself (or existing contributors working on unfamiliar parts of Parrot) to have a chance to get in-progress work accepted, knowing there will be time to fix problems, without always facing too many hurdles to acceptance. > So I guess my idea of the the status quo is, "until we can split our > thousands of obscure features into separate packages, we sorta just > have to live with them". But maybe we could have a happy medium: > suppose you only get opengl when you specify --enable-opengl on the > command line? Or it could be generated from "make opengl" or by > running "make" in a special directory or some such? This kind of > mechanism might not be good in the long term, but in the short term, it > should prevent people from stomping on each other so much. Actually, I would reverse these. In the long term, a scheme including --enable-foo flags seems reasonable (we already have --disable-foo, and the OpenGL steps respect --disable-opengl). In the short term, I think it's a bad idea, for the same reason that I think optimized parrots should be built by default. Anything that is not built by default risks not getting tested sufficiently now (when there is ample time to fix problems) before we get close to Parrot 1.0 (at which time if we discover a large problem, we are stuck with some hard decisions). > Another note, slightly off-topic: does OpenGL actually need a > configuration/detection step at all? I notice neither SDL or > PostgreSQL seem to have one. Maybe they're detecting everything at > runtime, or maybe their generated stuff runs from make instead of from > configure? I don't know this for a fact, but I believe that both of these predate the modern configuration/detection system, are not really integrated in the sense that everything Just Works after "perl Configure.pl; make", and don't have to address issues like different vendors providing incompatible headers. (In my case, different GLUT vendors disagreed about what the different GLUT API versions meant, which makes API versioning ... suboptimal.) > On the other hand, the config system is modularized into > nice neat little steps, which makes them terribly easy to write and > maintain, so it seems a shame not to use them. :) Well, I wouldn't call them "terribly easy to write", but I do think the basic config design makes a lot of sense, and legacy components (like the aforementioned SDL and PostgreSQL) should probably be updated to use this system. For what it's worth, though the process was difficult, I am happy with the results of using the official config system for my OpenGL code. -'f
