[development] D7 contrib module development

[Nathaniel Catchpole]

> Sure. But what is the prior goal of the Drupal project? To create a healthy
> vibrant community? Or to create the best open source CMS CODE out there
> (best accomplished through a healthy vibrant community)?



If we lost all the code tomorrow, we'd have 400,000 to put it back together
(even if 1% of that are active coders that's still 4,000 people to actually
write it). If the community gets collectively pissed off, everything falls
apart.


>
>
>  So what if we have a few extra gigabytes of code? So
>> what if they become unmaintained?
>>
> Uhhm sorry i don't share that so-what mentality. I want to have *all* the
> functionality spread over slightly different modules with the same purpose,
> combined into one flexible solution. And i am quite sure i am not the only
> one.


This is already happening - every release, Views and CCK make another 1-200
modules obsolete. That some modules get ported anyway makes them more
obsolescent than obsolete - but unless all the maintainers provide
rock-solid migration paths (much harder than a port), there's not much to do
about that.



 If we raise the barrier or block new entries we will be shutting
> ourselves off from being the platform for the new chx or the new
> merlinofchaos.
>
Woow stop for a minute please.. so you're saying people like chx or
> merlinofchaos are not capable of adapting to coding standards and qualified
> to contribute code which can be worked on to raise over the ready-and-useful
> barrier to be included in the official Drupal repository?


Most of our major contributors didn't start off in the Drupal community
fully formed and descended from heaven, even chx and merlinofchaos. In terms
of core contributors - I''m credited with a lot of patches against Drupal 7,
I pretty much learned PHP reviewing and writing patches against Drupal 6. If
my interest was in contrib rather than core, your new rules would've been a
major barrier to getting involved. Fortunately anyone can upload any patch
they like to the core issue queue, getting beyond that is where it takes a
lot of effort.

And we already have a filter for people applying for a CVS account which
tries to weed out the worst quality code or obvious duplication.


 It does not matter ... if it is the wild wild west, then let it be. It
> is a small price to pay for innovation and the power of the masses.
>
But the thing is, sometimes innovation needs channeling. Granted, in the
> early phases of the industrial revolution it would have been
> counterproductive to regulate machines and processes in any manner, simply
> because not enough practical experience had been gained. But once a certain
> level of sophistication is reached, there is no way you want to live without
> agreed standard interfaces and common norms.


Standards are emergent. Look at USB, high definition DVDs, RDF, SPARQL etc.
The car industry is a terrible example to give, given most modern cars are
really inefficient, and the whole thing is collapsing at the moment.


>
> In my opinion with D7 we have reached that level of wild life experience to
> benefit from a more ordered development process. To say again, why trade in
> quality for quantity/speed? Most people will be quite happy with D6 for
> years to come.


Have you looked at Drupal 7 yet? How familiar are you with the core
development process? While I'd love to see some consolidation in contrib, I
don't see any realistic proposals for handling this, rather than mythical
hordes of people who'll magically appear to review patches for contrib as
well as core.

I'd love to see code quality metrics (both coder and test coverage) for
modules, and that combined with usage and other metrics. With that, the
unmaintained modules will naturally get filtered out to the bottom.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090309/dda0c9c3/attachment-0001.htm