[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
--
*Scott McLewin*
www.folkjam.org
find jams. post jams. play well with others.
<http://www.folkjam.org>
More information about the development
mailing list