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>