[development] Code duplication, collaboration, and sandboxes. Oh my! (was: Custom Theme Settings)
Earnest Berry III
earnest.berry at gmail.com
Sun May 13 17:23:16 UTC 2007
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 at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of John
Sent: Saturday, May 12, 2007 9:54 PM
To: development at 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
More information about the development
mailing list