Why: In contribs they can settle out. Become nice. Grow onto people. In contribs they can conpete. I still think that there are other ways that make just as well a candidate for core. My own sympal scripts are just one of the possibilities. we are now getting apt-get alike module installers in. Fixtures are still in the make.
Why stare blind on one install system that is not tested, not mature and has not proved to be the Right Solution? Why depend only on those that can review patches, when we have a huge reviewing organism called "contribs"? Only because the Mob demands install systems? If they do so, lets give it, in contribs. And let that Mob sort out what the best stuff is, what needs fixed and what should be changed.
I'm sorry, but I couldn't disagree more. Contrib is nice, and it's an essential part of Drupal at large. But I don't think anyone would pretend for one minute that contrib modules get as much and as thorough a reviewing as a core patch. In contrib, the rule is "if it works, I'm happy" aka scratch-your-own-itch. Now, I'm well aware that there is a huge range of quality in contributed modules, going from the festering pile of stale spaghetti to the shiny clean and modular approach of e.g. CCK and Views. But nowhere in contrib is there a formalized and highly visible process for review, nor is it necessary. If I don't like a particular approach, I will ignore that module and look for something else. Whereas if a patch hits core that seriously hinders my needs, I'm screwed. If, as you say, making a good installer that works everywhere is a difficult endeavor, do you honestly believe that a mere contributed patch/module/script will get enough exposure for those issues to be discovered and fixed? Our development history has shown time and time again that getting in large changes into core as early as possible (but not earlier!), benefits everyone in the long run. A patch sitting in the queue is about a lot more than just looking for bugfree code. It's about getting everyone's opinion and approval, and making sure that the solution we end up with is good and flexible enough to be installed on /every single Drupal site out there/. If you wait for competing solutions, all you will end up with is N different approaches that will each work in one particular scenario. There is in fact a very analogous issue being worked on: to improve the Javascript functionality in Drupal Core. I have no problem with recoding parts of drupal.js and bringing in an external library, if it helps JS functionality get more exposure and development time. However, I think the JS work that has been done in contrib has had very little effect on this upcoming decision: those efforts are mostly started from a "scratch your own itch" perspective. Again: that's perfectly fine, for contrib. I have nothing against this. But as soon as things come near core, the discussion shifts to the needs of every Drupal developer and every Drupal site. I know that you feel burned by our review process... but your comment that the patch queue is only open "to those that can review patches" is plain nonsense. It is open to anyone who wants. Newsflash: I'm in the middle of my final exams and I still spent over an hour figuring out and reviewing that install patch. Why? Because I /want/ the installer into core, but I also want it to be the right solution. For me, it needs to be secure, usable, flexible and bugfree.... but most importantly, simple and elegant. The only people who consider reviewing to be "staring yourself blind" are those who are never done a proper review. Even more, the best reviewer does not just comment, he takes the patch and starts working on it himself: "Talk is silver, code is gold". It is not a mindless mantra, it is exactly the reason why Drupal is what it is today. Steven Wittens