[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