Here is a practical interim suggestion:
-Split the TinyMCE module into two parts:
1. a Drupal module
2. a second module which is just a container for the TinyMCE libraries patched for Drupal and ready to go.
-Host the first module on
Drupal.org and the second externally
-Make the first module dependent on the second with clear instructions about where to get it from.
That way TinyMCE will still show up on the statistics as one of the most downloaded modules (which was one of the main reasons for not hosting the whole thing offsite), but we avoid all the arguments about hosting foreign code in the CVS.
I firmly believe that in the case of TinyMCE an exception should be made to allow the modified library into CVS, but this might be a step towards that goal without upsetting anyone.
On 5/25/07, Tao Starbow <starbow@citris-uc.org> wrote:
> As I see it, the commit of 3rd party libraries in Contrib generally should not be allowed as:-
>
> a) It basically creates a duplicate code repository of code that should be availble from a single authoritive source.
>
Or you can see it as creating a tested version known to work with a
given version of a drupal module. This is the entire idea behind
versioning! Otherwise, if I create a drupal module that interfaces with
a 3rd party code base, I need to: chase after their development; see if
their latest version breaks my drupal wrapper; put info into the README
like "only works with version 1.3.1" (which will be ignored by many
admins); and then somehow deal with the possibility that the 3rd party
might stop offering version 1.3.1 for download.
> b) Uses
Drupal.Org resources to effectively host "someone elses work".
>
Or you can see it as using drupal.org resources to make things much
easier for drupal administrators.
> c) It's potentially a security risk, especially if maintainership is slack. Although problems aren't Drupal related directly it presents a sloppy view of the project as a whole imho.
>
I am still not understanding this argument. Right now I can create a
Hackme module that, say, emails your database password to all of your
users on instillation. I can upload this module as a project to
Drupal.org and have it hosted by drupal cvs. I, or any of the hundreds
of other unaudited developers, can accidentally create modules that open
up your site to cross site scripting. The security risk of the current
setup is pretty much infinite. How does allowing 3rd party code
increase it? And how does making someone download that 3rd party code
from a different source decrease it?