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>
|
