[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
michael at favias.org
Mon May 21 20:12:32 UTC 2007
Karoly Negyesi wrote:
>> I don't understand what's so inconvenient in allowing external files.
> 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.
Im of the alternative opinion that most module maintainers will be a
little more keyed into upstream progress for third party code than the
average module user. While it doesnt solve your problem of "I do not
want Drupal distributing insecure code." It does mitigate the real
problem of drupal users actually using insecure code on their websites
as it is outdated, etc. Why not centralize the management of the code,
this is one of the purposes of version control systems in the first
place. To avoid duplication of effort. This isnt drupal core we are
talking about these are contrib modules that im sure have a number of
flaws anyway because of their less robust testing and security audits.
Arguments "for" such a centralization:
* Ease of installation/upgrading use for user base.
* Less trouble diagnosing issues on modules with third party libraries
because you have 1 fewer variable.
* Core Update Status Module to alert users automatically of new versions
that include may include security updates.
* The average module maintainer is probably going to be paying more
attention to the upstream project than the user and is thus more likely
to be aware of issues and also has the power to roll in the fixes and
release thereby notifying everyone involved.
* Module incompatibilities often require that people get a specific
version of 3rd party library/code and this can be tough to instruct
people to follow.
* fewer unnecessary bugs regarding library mismatches, etc
Arguments "against" such a centralization:
* Third party libraries can and will fall behind the official source
with regards to vulnerabilities, security patches, etc a vigi=lant user
might know or fix theses issues faster.
* Duplication of code management with upstream.
* licensing (discussed LGPL, etc)
* module developer under less pressure to upgrade module to work with
newest upstream version slows down innovation, etc
I for one think that a good argument is made for centralizing this code
management and easing the burden of our users without impacting the
module developers (it is optional right?) I don't see how it can't be a
mitigating factor for migrating users off of old libraries if you accept
the proposition that the average maintainer follows the upstream project
closer than the average user. But perhaps this is flawed logic.
Michael Favia michael at favias.org
tel. 512.585.5650 http://michael.favias.org
More information about the development