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

[Kevin Reynen]

It looks like that's where we are headed.  I encourage anyone interested in
helping to improve TinyMCE (both the module and the Drupal specific version
of TinyMCE itself) to join the TinyMCE Development group (
http://groups.drupal.org/tinymce-development).

It was never my intention to incite such a long debate on the issue of 3rd
party libraries.  The truth is I can't do what Gerhard does from Drupal.org,
so this could have ended when he said this would be too much of an issue for
the people maintaining CVS.  IMHO the 3rd party policy is going to need to
be revised for JQuery plugins, but I've conceded that we need to find a home
for at least part of TinyMCE.

We're looking for feedback on the (next) best place to host Drupal specific
development (http://groups.drupal.org/node/3364) now.  If you have
suggestions, please join that group and make your suggestions there or email
me directly.

I think everyone has had enough of this thread.

- Kevin Reynen

On 5/25/07, Andrew ft <andrewft at gmail.com> wrote:
>
> 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 at 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?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070525/91309da9/attachment.htm