[development] D7 contrib module development

[Nathaniel Catchpole]

>>  Who's talking about dictating.. Everyone can code freely. But for code
to enter the official repository, quality >>checks should apply. That
doesn't stop innovation, does it? Look at the few commits to the cck/views
branches >>for example. Why is that kind of responsible code committing not
scalable to all other modules as well?

We already have a way for code to get reviewed before it gets committed to
the repository, it's called patches.

The gatekeepers for core aren't just the two committers - there's also a
whole layer of people who regularly review patches before they get
committed, not enough of them, but  that's how the code for core gets
filtered.

There are 92 pages of patches which need review against core or contrib. If
we could fine people to review all of those patches intelligently - not to
mention dealing with new bug reports and support requests for the top 200
most used modules, that'd help to consolidate efforts a lot. Anything else
is putting the cart very, very far before the horse.

http://drupal.org/project/issues/search?text=&projects=&assigned=&submitted=&participant=&status[]=8

That doesn't include all code marked for commit or needs work which nearly
doubles that number.

Or to put it another way, count the number people who reply to support
requests, let alone post and review patches for the Views issue queue. It's
a small number of overworked people. The people working on core and the 'top
40' (or 100, or 300) contrib modules are buried in issues, don't get nearly
enough help with their projects - but then you want these people to review
every commit as well?

>>No - the swarm, that is us. We all work together on finding the best way
to lay the foundation for the respective >>functionality. Aren't we already
doing that with core? Is it impossible to apply to non-core modules?

Yes it's impossible unless we massively increase the people dealing with
support requests, bug reports and patch reviews for the major modules which
have already 'won'. Let alone co-ordinating efforts to merge
smaller/duplicated/abandoned modules as time goes on.

>>Why is not letting experimental code into the repository stopping people
from trying stuff out? Please explain that >>to me, i simply don't get that.

A lot of sandbox projects on Drupal.org have turned into great modules or
core patches - often resurrected by people other than the original author.
Having all this code centralised is a good thing and isn't going to change.
What will hopefully change is filtering those projects from the most widely
used and supported ones for new users - again, there's efforts to do this
both with the redesign and numerous feature requests to project*.

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