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

[Matthew Farina]

At this point a number of merits for both directions have come out  
here.  Currently the policy is to not have them in CVS.  What would  
it take to change that policy?

On May 24, 2007, at 3:04 PM, Kevin Reynen wrote:

> I had conceded to host the Drupal specific version of TinyMCE  
> myself, but Tao's message was interesting enough to suck me back in  
> to this.
>
> Round 2... ding, ding
>
> Nedjo asked about the 3rd party library issue ( http://drupal.org/ 
> node/124978), but it looks like Jeff just went ahead and uploaded  
> the files he wanted to use to CVS as part of the modules instead  
> including links and documentation for where to download the files  
> and how to install or configure them.
>
> Jeff includes unmodified? versions of jquery.js 1.1.2 and compat. 
> 1.0.js (http://dev.jquery.com/browser/trunk/plugins/compat-1.0) in  
> jQuery_update.  The interface.js (78k) included in the  
> JQuery_interface is available from the developer at http:// 
> interface.eyecon.ro/changelog
>
> I also found it here...
>
> http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/ 
> interface.js
> http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/ 
> interface.js
>
> Ironically, you can also find the WordPress optimized version of  
> TinyMCE in wp-includes as well...
>
> http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce
>
> TinyMCE IS included as part of the WordPress "core", but as a  
> customized/optimized/compressed version with a small number of  
> plugins  ( http://trac.wordpress.org/browser/trunk/wp-includes/js/ 
> tinymce/plugins).  By dropping  the
> _src.js files and unused themes/icons, the WordPress TinyMCE is a  
> much smaller download.  They also include WordPress specific plug- 
> ins for functionality and help.  These are the types of  
> optimizations I'd like to be doing to TinyMCE for Drupal, but the  
> current CVS policy requires me to host a Drupal specific version of  
> TinyMCE myself.
>
> For the TinyMCE module, it doesn't make a whole lot of sense to put  
> the required library in another download since the module's sole  
> purpose is to enable and configure the TinyMCE library, but if  
> other modules requiring external libraries standardized on how the  
> libraries are handled I'd go along for that ride.  Assuming there  
> are no licensing conflicts, libraries could be treated as modules.   
> Library dependencies could be handled by the .info, someone would  
> have 'own' the security and support issues related to the library  
> just like maintainers (in theory) own these for modules, and  
> version conflicts between developers using a common resources could  
> be worked out the same way they are now.
>
> I don't know what the ramifications of this suggestion would be for  
> the people maintaining the CVS, but there are obviously active  
> developers who are frustrated by the policy and others who are just  
> ignoring it.
>
> - Kevin Reynen
>
>
> On 5/24/07, Tao Starbow <starbow at citris-uc.org> wrote:
>
> > aps to address this concern, we could create a dedicated module that
> > simply provides the third party library in question and little or no
> > additional functionality as required by drupal. The the modules that
> > depend on it can do just that in the info files. Avoids duplication
> > and centralizes the management and ability to audit for security
> > issues too boot.
>
> This is the approach Jeff Robins has taken with his jQuery_update and
> jQuery_interface modules, and I think it works very well.  This  
> approach
> leverages Drupal's project versioning and dependency systems to  
> keep the
> 3rd party (GPL) code insync with the Drupal code, and simplifies
> instillation.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070524/1acbc7c2/attachment-0001.htm