[development] An alternative to common thinking in 5-> 6migration

Daniel F. Kudwien news at unleashedmind.com
Wed Mar 11 11:50:54 UTC 2009


> Well it is apparent to me that noone brought up any 
> compelling arguments against it (besides 'dont like'). Some 
> people however voiced their annoyance about the current 
> situation - especially with module duplication - which has 
> not been addressed adequately by anyone. Also up to now, the 
> only approach to tackle the other existing real problem of 
> overloaded, unresponsive and uncooperative module maintainers 
> which hold the sole keys is mine. No alternative concept 
> (except the new project queue idea, which has been already 
> mentioned to not catch many of the cases) has been proposed. 
> Yet if nothing is done, shit will just again hit the fan.
>   regards, marcel.

Previous posters brought up arguments, but you obviously did not understand
them.

Refining the list:

Unresovable causes for duplication:

- Developer wants to implement things differently than maintainer and is
unable to agree with maintainer.

- Maintainer of existing module does not accept developer's contribution and
also does not accept developer as co-maintainer.

- Developer takes over existing project and turns it into something that was
never intended.


Resolvable causes for duplication:

- Developer did not search.

- Developer did search, but existing module uses different lingo.

- Developer did search, but did not realize that existing module does the
same in an abstracted way.

- Developer was not able to imagine that his contribution would be accepted
in existing module.

- Developer was too lazy to grasp the API of existing module, better write a
new one.

- Developer spent weeks of coding in private, now he must release, even if
it's 100% duplicate (ego).

- Developer did not know about CVS sandboxes.

- Developer wants to attract clients (ego).

- Developer does not know how to patch, just learned how to use CVS from the
handbooks.


Given this list, a new project moderation queue would possibly be able to
eliminate 75% of duplication causes.

So what if this moderation would _blindly_ accept the above mentioned,
unresolvable causes as reasons for creating a new project without further
backtalk?

I could even imagine that the content of this queue can be very interesting
for all Drupalers - "I'd like to create a module that does X." - "Why don't
you use Y with Z?" - "Bingo!"


sun



More information about the development mailing list