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

[Kevin Reynen]

Some people seem to have missed this point...

I want to CHANGE the configuration of TinyMCE from Moxiecode's default
configuration to eliminate the double filter issues for Drupal users.

I can legally do that because the libraries are licensed under LGPL.
I can also legally distribute the customized TinyMCE with open source
(or even commercial) software.  There are several CMS and blogging
packages that distribute customized versions of TinyMCE instead of
asking their users to make the configuration changes and then dealing
with the support issues that creates.  IMHO, this is a much better
solution for the everyone involved, but if 3rd party libraries are
never going to be rolled into Drupal releases through CVS or some
other method, what do you suggest?

1) Distribute single step "official release" of TinyMCE outside of
Drupal and don't worry about any download lists or the precedent
having a popular module distributed outside of Drupal sets

2) Leave the multi-step install/configuration in place and spend my
time answering the same questions over and over instead of developing
new features... or just tell those users to RTFM and leave those
questions unanswered

3) Set up my own CVS/SVN to distribute the Drupal customized version
of TinyMCE and either build an autoinstall for external libraries into
TinyMCE or hope someone adds that to a module like Update Status

None of these seem like ideal solutions, but I'm leaning towards #1.
I'd rather spend the free time I have this summer developing new
Drupal specific TinyMCE buttons to make publishing rich media easier
for my users (and making people aware of the other user contributed
buttons available for YouTube, PHP editor, unicode keyboard, etc) than
answering the same support questions or developing an auto-install
process.

If the CVS policies are changed or a way to easily incorporate 3rd
party libraries is developed, I'll be glad to move the "official
release" back to Drupal.org.

- Kevin Reynen

On 5/22/07, Jakob Petsovits <jpetso at gmx.at> wrote:
> On Tuesday, 22. May 2007, Lodewijk Evers wrote:
> > Why not to add it to the drupal CVS repository:
> > If the FCKeditor were uploaded into CVS that would mean that there would
> > be ~500 extra files in the repository, which just isn't clean and
> > proper. CVS is for tracking development, and since no-one in their right
> > mind will be developing for the FCKeditor or tinyMCE project in the
> > drupal repository (that would be a fork of those projects) it does not
> > make sense to include those files in there either. Those 500 files will
> > just be doing nothing there and taking up resources like a fax modem in
> > a centrino laptop.
> > A guideline could be that if a project has a repository of their own,
> > and even a complete developer community - don't even think about
> > importing it into the drupal repository.
>
> I completely agree here.
>
> A possible solution to that problem could be one or more description files
> which cause drupal.org to download a file when a project release is created,
> and optionally unpack it in the folder where the description file lies.
> You get the idea:
>
> /tinymce.fetch:
> url = http://ovh.dl.sourceforge.net/sourceforge/tinymce/tinymce_2_1_1_1.tgz
> description = "TinyMCE source package"
> archive = tgz
>
> When the release is created, the url is downloaded, extracted with tar into
> the module's root folder, and the tarball's contents (the tinymce/ folder)
> are packaged together with the module.
>
> This does not solve the security issue (assuming that this really matters) and
> does not solve license incompatibility issues (which can still be tracked
> though, by inspecting release tarballs of modules containing .fetch files or
> downloading the url manually), but it does solve the code duplication
> problem.
>
> It's not up to me to decide if the remaining problems are big enough to keep
> up the restriction.
>
> Cheers,
>   Jakob
>