I agree. I think an "announcement" of some sort before going live would benefit to help reduce code duplication. I know that I am just as much adding to the problem as anyone else (e.g. with my pontomail, I should have used MimeMail on the send part of the module instead of writing my own sendmail function...currently refactoring/writing). I would like to see drupal go the way of the unix methodology, meaning many small tools, which when used in collaboration, can do powerful things. This doesn't mean an explosion of small simplistic modules, what I mean by this is there are some module functionalities that should be "generalized" into an api, and used by other modules so that we don't duplicate the same functionality. Token module is a good example. I think there should be more of these "API" modules, so that we're "extending" functionality, not re-writing functionality. Just my 2 cents. Now, how to go about controlling this and implementing this is another discussion. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of John Sent: Saturday, May 12, 2007 9:54 PM To: development@drupal.org Subject: [development] Code duplication, collaboration,and sandboxes. Oh my! (was: Custom Theme Settings) On May 12, 2007, at 8:06 AM, Earnie Boyd wrote:
How can this be controlled? What methods could be put into place to help reduce the duplication? Self policing doesn't work well for these situations. We need some stronger methods to control the desire to create YA module of the same function.
Actually, Frederic and I exchanged about 4 emails on April 8 regarding the 2 themesettings modules. But it seems he has forgotten. So self policing actually did work in this situation; we were both aware of each other's code and I invited him to collaborate. I agree with Earnie that 2 YA-solution _projects_ are indeed a problem, but 1 project and 1 sandbox module... not so much. Collaboration & the sandbox: What are the uses of the CVS sandbox? If the sandbox is supposed to be a place where people can collaborate before a project is created, perhaps a CVS repository associated with the groups.d.o website would be more useful. Code duplication: Perhaps it needs to be a requirement that module developer's announce their project on this list BEFORE any code becomes public on the d.o website. I'm not sure how we could enforce that requirement, but perhaps just documenting it in the appropriate places in the handbook would be enough. Any other suggestions? - John