[development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
drupal.user at albin.net
Fri May 25 13:32:21 UTC 2007
On May 25, 2007, at 12:29 AM, andy at spiders-lair.com wrote:
> As I see it, the commit of 3rd party libraries in Contrib generally
> should not be allowed as:-
> a) It basically creates a duplicate code repository of code that
> should be availble from a single authoritive source.
> b) Uses Drupal.Org resources to effectively host "someone elses work".
> c) It's potentially a security risk, especially if maintainership
> is slack. Although problems aren't Drupal related directly it
> presents a sloppy view of the project as a whole imho.
a.) We wouldn't be distributing the library by itself; it would be
packaged with some higher-level code. Nowhere on d.o would it say "If
you want this library, get it here!"
b.) As it relates to Drupal Core, contributed modules are ALREADY
someone else's work. As it relates to Drupal as a whole, including
GPL code form other sources is the very spirit of open source (as
Jeff just said.)
c.) If the maintainership is slack, the security risk is already
there; the sloppy view of Drupal as a whole will already be there. It
makes no difference if a 3rd party library is involved. Also, as a
counterpoint: a good maintainer will monitor updates to a 3rd party
library. And the good maintainer will always be more secure than the
I keep seeing the "security risk" reason repeated. But it seems
people are really talking about the /perceived/ security of Drupal as
a whole and not the /actual/ security of the average user's
Contrib modules are much more likely to get updated by the average
user now that we have Update Status. But forcing a user to download
and install a separate library means that library will most likely
never be updated again.
For /actual/ security, we need to allow 3rd party libs in Drupal's
CVS (for the reason in c above). As a compromise, we could make
contrib authors apply for special 3rd party library inclusion into
CVS as Derek suggested and to then trust them to keep that 3rd party
library well maintained. The CVS 3rd party lib application could be
approved or denied based on the maintainers proven track record on
previous modules. So newbie developers would be denied and
maintainers like JJeff would need co-maintainers before the start of
the project. (I'm not picking on you, Jeff! I love your code!)
For /perceived/ security, maybe the best way to fix contrib from
affecting Drupal core's good name is to put the distribution of
contrib on a separate domain or sub-domain. Like 3rd-
party.drupal.org or unofficial.drupal.org...
More information about the development