[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?

Scott McLewin drupal at mclewin.com
Wed May 23 12:27:59 UTC 2007

Karoly Negyesi wrote:
> It's very simple. When there is a security fix released for the 3rd party code then our repository necessarily will be some time behind -- if the maintainer is sloppy then seriously behind. I do not want Drupal distributing insecure code. Solve this problem and we can move on. 
If a maintainer is sloppy their own code is likely to be insecure 
without any help from a third party library.

There is another very simple that incorporation of third party code into 
modules leads to a path that adds work for the CVS maintainers.  The use 
of the same third party code in two or more different modules opens up a 
few issues for sites that wish to use both modules together.  Do you run 
with multiple copies of that third party code in your deployment?  What 
if those copies are at different rev levels?  What if they outright 
conflict with eachother, such as two jQuery versions might? 

When third party libraries become popular they benefit from a move into 
core, like jQuery did, and at that point they become the responsibility 
of the CVS maintainers to manage.  This is a perfectly healthy 
progression, but it is one that has 'handle with care' stamped all over it.

Perhaps the argument is less about whether to allow 'foreign' code into 
the CVS contrib area and is more about how to decide which third party 
libraries to bless as part of core - preferably an optional part that is 
only made active by a module that needs it.

Have I missed the point entirely?  Apologies if I have...


*Scott McLewin*
find jams. post jams. play well with others.

More information about the development mailing list