[development] An alternative to common thinking in 5-> 6migration
metzlerd at metzlerd.com
Wed Mar 11 15:13:45 UTC 2009
On Mar 11, 2009, at 5:45 AM, Marcel Partap wrote:
>> Previous posters brought up arguments, but you obviously did not
> Where are those? Despite
> - it would place all load upon a small load of developers who are
> already overloaded (not true)
> - would stiffle innovation (hardly true - restriction only on repo
> - don't like it because it messes with my ways (can't argue with that)
> there was no argument i am aware of, and none of those strike me as
> real compelling evidence quality restriction would be a bad idea.
Sounds like there's two threads here, one about avoiding unnecessary
module duplication and another about improving quality of code that
does get committed. We've mostly been talking about the former. But
I sort of feel like commit time is way to late to be talking about
strategies for eliminating module duplication anyway, so.....
The current documentation on drupal.org basically suggests you should:
* to produce your contribution.
* to apply for contributor privileges.
In the interest of moving this forward/closing this. I've opened an
Which discusses adding guidelines for vetting your module idea. If we
have a process. Now there is already the Joining Forces With others
doc at http://drupal.org/node/23789. Which describes the desire to
communicate, but if there's a recommended protocol, perhaps we should
include it in the basic process description?
The stifle innovation argument is valid although you've called it
invalid several times.
You have proposed that 10 (not high profile) developer reviews would
be required in order to commit code. Assuming you mean what you say
and the overloaded developers (high profile) don't have an increased
workload, then that means i need 10 reviews to get my code committed.
I maintain a non-duplicative module that plays an important role in
universities that are doing single sign on with drupal. I have
struggled with getting ONE person to review my patches, but my code
does get reviewed at my place of work, outside of the drupal
commmunity. This project would likely not be viable on drupal.org
under the solution you describe.
There are several ways for you to get involved in patch reviews:
1. Play Contrib patch Bingo
2. Filter the project issue queue by Feature Requests that are Ready
3. Subscribe to the issue queues of projects you're interested in
I would add my voice to the voice of other that suggest that there
are more effective ways for us all to spend time improving quality of
contrib code, the biggest of which could be joining the developer
More information about the development