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@favias.org tel. 512.585.5650 http://michael.favias.org