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-----