[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?

[Michael Favia]

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.

<snip>
> 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 
statements.

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