[development] Consolidating duplicate contrib modules for D7

[Ken Winters]

Huge -1 to free-for-all commits in contrib.

If you want to contribute code to a module, do it by providing a patch  
in the issue queue.  The reasons for this are legion:

* The code needs really needs to go through more than one person  
before it is released to the public.  The issue queue is the  
appropriate way to handle that.
* The maintainer still really should be the only one creating release  
tags, and for that matter is the only one that can edit the project  
page and create the release nodes.
* Sometimes a change can be great on the surface but have horrible  
consequences.  The person who is most likely to know this is the  
maintainer, because they have the most experience with that code.   
Note that core is the extreme of this, with massive interdependence  
and 2 committers.
* A corollary to the above: the ability to commit is clearly not a  
requirement to contribute, which is clearly evident in the number of  
core contributors.
* If anything I'd say this would discourage people from contributing a  
module, since other people breaking their code is now a hassle they  
have to deal with.  A broken patch file in an issue is neither  
stressful nor urgent.
* This change doesn't solve any real problem (especially eliminating  
forks).  If the maintainer is not doing their job, there is a process  
for replacing them.  If that process needs work then fine, but it at  
least mostly works when it is used.

- Ken Winters


On Dec 7, 2009, at 10:12 PM, Marcel Partap wrote:
> Instead, IMHO, the responsibility for contrib code development  
> should move from indiviual people to the collective, i.e. every  
> svn ... uuhm cvs account holder should have commit access to all  
> code. Sounds unmanageable at first but seems to work out very well,  
> f.e. with the KDE project. It's kind of like the shared space 'urban  
> design concept' (http://en.wikipedia.org/wiki/Shared_space) - a lack  
> of strict regulation means individuals have to care a lot more about  
> their interaction with other participants. This way communication  
> _and cooperation_ actually become obligatory to making decisions -  
> consequently a more swarmwork-oriented style of interaction evolves.  
> (..and in contrast to real world shared space traffic, in the rare  
> cases where this process fails and b$ code changes indeed are  
> committed, it's very easy to roll back and rework.)
>
> So imho Drupal contrib repository should be freed from only- 
> maintainer-writable-restriction to accessible-for-all-devs. The new  
> way of avoiding bogus code commits is not to prohibit developers  
> (who might be perfectly qualified for the task at hand) from  
> changing certain code, but by giving more clearance to everybody.  
> With more power comes more responsibility of course: covert,  
> disagreed code changes are only prevented by social mechanisms, not  
> repository access rights.
> To reiterate: this process works perfectly well for KDE: although i  
> have only done some tiny commits here and there, my SVN account is  
> not limited! Nothing there to prevent me from committing havoc to  
> core kdelibs code straight away, right now... Still - it never  
> happens!
>