[development] Consolidating duplicate contrib modules for D7

[Marcel Partap]

> No one claimed to be able to solve EVERY problem. According to the
> thread title, the problem being solved is the duplication of modules.
> And neither a DCVS nor a commit-access free-for-all will ultimately
> solve that. People are going to disagree about what the objectives for
> a module should be, and there going to disagree about what constitutes
> "technical superiority."
That might well be. But the most important thing to avoid functionality overlap is to engineer frameworks that are capable of handling as many different, probably conflicting, use cases that could be come up with. Then code not agreed upon can be refactored into submodules for the framework, instead of reimplementing functionality multiple times in conflicting ways.

> The solution to such roadblocks is social, not technical. Good
> old-fashioned human interaction, communication, deference, and mutual
> respect. "Blessed are the peacemakers...."
The solution is both, of course. Technical utilities that support the social workflow ;)
The thing is, abolishing individual persons' OWNERSHIP on code in D7 contrib does away with possible prevention of code improvements due to social factors. By itself, it does not solve any problem of course, even giving room to a new one: people at will committing changes NOT coordinated with one another. To prevent that, important thing is to start implementing the potential frameworks ASAP and make sure they can properly be expanded by extensions/submodules. This process will naturally result in a voluntary group of developers doing the job of maintenance.

> Showing up and demanding that everything change in a workflow that
> you've never participated in...
What does that mean? I have provided patches to at least a dozen modules, and core.

> that's not going to win friends and influence people, and it's not going
> to produce better code or fewer duplicate modules either.
To put it bluntly, i am not trying to make friends, i am trying to stir up some discussion about the development process i am taking part in.

> Of course, I'm biased, because I think duplicate modules are largely a
> good thing. Let natural selection take it's course, I say.
For Drupal 6, no disagreement. Everybody and his dog tried his variation of how to implement basic functionality, and it has led to an impressive amount of creative programming work of (partly) high quality.
But duplication is bad in several ways which already have been mentioned multiple times before. Frameworks with beyond-dispute general structure are a good replacement for obvious reasons, so a development process which facilitates that is an improvement.

> One thing is for sure: KDE and Gnome wouldn't be nearly as good as
> they are today if they weren't constantly stealing and improving on
> ideas from one another.
Comparing <10KLOC modules with overlapping functionality with two rivaling desktop environments is stretching scales a bit. And with nested frameworks (payment framework -> paypal framework -> submodules) there's still room for competing implementations - the difference it makes is at which API level differences are visible. paypal_framework_1 and paypal_framework_2 might differ in internals and have incompatible submodules, but should both provide same functionality/interface to the payment framework. At the moment, there's no common payment framework, none for shopping carts, none for a variety of other applications, resulting in competing implementations in D6 contrib.

regards,
marcel.
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser