[development] Install profiles tutorial for Drupal 4.7, Friday 8AM PST

[Steven Wittens]

> 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