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

[Matthew Farina]

I cringe bringing this in but, this conversation covers smaller  
scripts such as jQuery plugins of which there are several in CVS.   
These are scripts that, uncompressed, are only a few kilobytes in size.

Not having an easy way for users to install these modules creates a  
big barrier for entry[1] for new drupalers.  While we may not have a  
problem installing outside scripts, is this a barrier worth doing  
something about?  I would prefer to see an installer that can  
download and install the outside scripts securely.  But, there just  
isn't enough time before the code freeze, as far as I can tell.

So, that leaves 3 options.
1)  Leave things just as they are with no outside libraries in CVS.
2)  Allow them in CVS with some sort of criteria for entry.
3)  Allow them in for now with a future path to have an outside  
installer

I would prefer to include them lowering the barrier for entry and put  
building a better installer on the the to do list.  But, I can live  
perfectly fine with #1.

Just my 2 cents.

- Matt

[1] http://headrush.typepad.com/photos/uncategorized/2007/04/06/ 
incremental1.jpg


On May 21, 2007, at 6:03 PM, Gerhard Killesreiter wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Favia schrieb:
>> Jeff Eaton wrote:
>>> The GPL requirement makes perfect sense. But it's not like anyone is
>>> asking the CVS repository admins to make sure that the TinyMCE
>>> libraries are up to date, neh?
>> In fact quite the opposite. Many times you have to specify exactly  
>> which
>> version of the third party library to download because you haven't  
>> had
>> time to rewrite the module to enable compat with the newest release,
>> etc. This does lead to a lot of confusion. While I agree that
>> maintaining shadow copies of third party CVS libraries isnt "fun"  
>> it is
>> useful and can be an efficient way to deal with helping our users
>> maximize the usability of drupal. And i think that most module
>> maintainers would rather deal with periodically updating their 3rd  
>> party
>> code than weed out all of the bogus bug reports and hand hold  
>> users who
>> are attempting to install and configure their modules one at a time.
>
> If that proves neccessary you should write some docs. Although e.g.
> listhandler module isn't one of the really easy modules, I don't  
> notice
> many issues with it. The docs are short but to the point and seem  
> to help.
>
>> In
>> any event shouldnt we leave it up to the maintainer at least to
>> determine which is most efficient to their circumstance?
>
> They are already free to determine what is best for them and their
> module. They are not free to commit to CVS what they want. They are  
> free
> to host a "my module with everything you ever needed to run it"
> somewhere else.
>
> Cheers,
> 	Gerhard
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGUhdEfg6TFvELooQRAmTQAKCUUVMhxRytFP4qfCexn9zfSjlzggCcDDuh
> 0rSi+bsoDsuDHWVhsWxZgQQ=
> =0DSQ
> -----END PGP SIGNATURE-----