[development] Consolidating duplicate contrib modules for D7
kwinters at coalmarch.com
Tue Dec 8 15:38:55 UTC 2009
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
* 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
More information about the development