[development] Consolidating duplicate contrib modules for D7

Marcel Partap mpartap at gmx.net
Wed Dec 9 02:14:44 UTC 2009


> 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:
Yes, that's the accepted standard approach, and it works well ~90% of the time. But that still means there's a _huge_ number of cases where it _does not work very well_.

> * The code needs really needs to go through more than one person  
> before it is released to the public.
How exactly do you define 'release to the public'? Commiting code to a development branch used only by developers? Or releasing ready-made quality-inspected module packages?

> The issue queue is the appropriate way to handle that.
Well yes, it is one feasible way to handle it.

> * The maintainer still really should be the only one creating release  
> tags,
Why?
> and for that matter is the only one that can edit the project  
> page and create the release nodes.
mmh.. What is the key characteristic of the internet project with the hugest growth rate in the last decade? (*)

> * Sometimes a change can be great on the surface but have horrible  
> consequences.
..ack, had that before ;)

> The person who is most likely to know this is the  
> maintainer, because they have the most experience with that code.
Actually - that's bad for core CMS functionality like messaging, file management, payment, workflow, isn't it? Is it not preferable to have a bigger group of people be involved and familiar to such implementations?

> Note that core is the extreme of this, with massive interdependence  
> and 2 committers.
Yes, but there are more than two people in the project capable of grokking every commit that goes into drupal core. These two 'just' mostly do the (highly critical!) job of judging code readiness (relying heavily of course on opinions voiced on the report thread), plucking the cherries from that big colourful issue queue tree ;==)

> * 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.
Breaking *whose* code? Is this still free software - or just freeware hosted on a common platform?

> * This change doesn't solve any real problem (especially eliminating  
> forks).
Not by itself, of course.
We shouldn't do software like some politicians do geopolitics (i.e. 'nicht zuende gedacht' ;)

> If the maintainer is not doing their job, there is a process  
> for replacing them.
Bureaucreacy (how tf is this spelled **g) to solve problems that wouldn't exist without it, we need more of it.

>  If that process needs work then fine, but it at  
> least mostly works when it is used.
Might be or not, it is a barrier, putting people off from contributing. And one's persistence to have his work published somewhere on drupal.org might not be correlated to that work's quality (means good sh1t might - instead of automagically being supported - lay stale = double plus bad)..

regards, marcel.

* hint: anyone can change any article in wikipedia, anonymously and instantly. That's a NULL height entry barrier.
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


More information about the development mailing list