[development] Consolidating duplicate contrib modules for D7

Daniel F. Kudwien news at unleashedmind.com
Wed Dec 9 02:41:04 UTC 2009


> 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?

Almost all projects have development snapshot releases that are repackaged
every 12 hours.  How much more is "public"?


> > * The maintainer still really should be the only one 
> creating release  
> > tags,
> Why?

Because the maintainer is "guilty" for the bugs that users experience,
regardless of whether its caused by own code, code by co-maintainers, or
flawed code introduced in patches by contributors.  Really, it seems you
have not maintained any project at all.


> > 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? (*)

You forgot that there is an armada of content moderators in your scenario.
This armada does not exist, especially not regarding the skill-level.  This
is not about maintaining documentation.


> > 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?

That's why we have modules, and that's why we promote a proper separation
between APIs.  That's why we have module dependencies.  There is no one who
understands all.  But we also don't need someone like that, because it's
sufficient to understand and focus on a particular sub-system or module.


> > 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 ;==)

Do those other people need to commit?  No.

http://www.unleashedmind.com/en/blog/sun/improving-drupal-cores-development-
workflow


> > * 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?

Breaking the code that users want to use.


> > 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.

Why would you want to contribute to a project, if you can't establish a
trust-relationship to the project maintainer?  Because, if you can establish
one, there's little that hinders you from becoming a co-maintainer, or have
your patches committed quickly.

Again, we want to encourage contribution and collaboration.  Not discourage
it.


sun



More information about the development mailing list