[development] Install profiles tutorial for Drupal 4.7,
Friday 8AM PST
steven at acko.net
Sat Jun 10 02:33:12 UTC 2006
> 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"?
> 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
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
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.
More information about the development