[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
michael at favias.org
Tue May 22 16:20:08 UTC 2007
Kevin Reynen wrote:
> Some people seem to have missed this point...
> I want to CHANGE the configuration of TinyMCE from Moxiecode's default
> configuration to eliminate the double filter issues for Drupal users.
Understood and appreciated.
> If the CVS policies are changed or a way to easily incorporate 3rd
> party libraries is developed, I'll be glad to move the "official
> release" back to Drupal.org.
This is a shame but i agree with your rationale. Version control systems
arent for for "managing development" as previosuly stated in this thread
but instead are supposed to help "manage code" and this often includes
third party code in the form of independent vendor drops. There is
actually a chapter in the red bean SVN book about the best practices to
managing this process. While i understand that nobody wants to ship
vulnerable code with drupal (neither do i) i think that we are selecting
the greater of two evils. There are so many advantages to allowing
reasonably sized libraries that are licensed under the GPL and i have
seen absolutely ZERO recognition of these palliative effects by the
individuals rejecting the idea. We've made some reasonable arguments for
the inclusion of this GPL code and i havent seen any rebuttal or
rational argument against the values but instead unsupported declarative
I certainly dont speak for anyone but my self but I would like to put
out a concise argument for the position that many developers and myself
seem to share:
The allowance inclusion of the "reasonably sized" third party libraries
will ease the pain of installing, supporting and improve the average
users ability/liklihood of keeping their modules and third party
libraries updated. The average module maintainer is more likely paying
closer attention to the upstream developments and vulnerabilities than
the average user and can patch the module when it is advised to do so.
After which, the update status module (newly included in D6 core) can
automatically and instantly notify affected users when a new version
becomes available. This also eases the pain of having to support a wide
variety of available versions for modules that rely on third party
libraries and allows the module maintainer to make changes to the GPLd
code where necessary to better interact with drupal. We believe this
outweighs the real and possible disadvantages which include the
possibility that "stale" and vulnerable code will be shipped with a
drupal module (we think that this incidence will be less widespread than
the current situation that requires individual users to track and update
their third party libraries themselves resulting in the net improvement
mentioned above), we also believe that the benefits outweigh the extra
work required to maintain the third party library in version control in
part because of the amount of time otherwise handling or debugging
poorly setup or configured installs on a very repetitive basis no matter
how good the documentation is (surely chx can vouch that no matter how
well you document something people will either not find it, not read it
or misread it [e.g. cvs]).
I have tried to present all of the points mentioned in this thread and
address everyones issues in turn. Please forgive or correct any
omissions to that end. I would appreciate a measured response to this
argument if anyone has the time or inclination. All the modules
maintainers are asking for is the permission to make the decision that
is best for their module and that makes their continued support and
improvement of that module most efficient to them. I personally think
this is a reasonable request with enough benefits to relax the current
restrictions slightly and give it a shot.
Michael Favia michael at favias.org
tel. 512.585.5650 http://michael.favias.org
More information about the development