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

[Lodewijk Evers]

Kevin Reynen schreef:
> 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.

In other words: You want to fork tinyMCE and maintain a drupal specific 
version in the drupal repository

Yes you MAY legally do that, but I don't think the drupal repository is 
for doing that... so the question remains: SHOULD you do it? If other 
people do it that does not automatically imply that drupal should do it too.

Is there a possibillity in tinyMCE to use external configuration files 
and modules?
I know FCKeditor has that porssibility. So if tinyMCE can do that, you 
could include the drupal specific configurations and modules in your module.

> 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 

You're free to do that, but you will have to do your own publicity then, 
and at the moment the drupal.org infrastructure does not help you with 
that. Maybe an "externally published modules" section could be created 
for projects like that (Ecommerce andcategory might be candidates for that)

> 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 

Giving an end user the responsibility for downloading the right version 
of a component from an external site should not be a problem IMO, after 
all, someone installing drupal SHOULD know how to do that, or be able to 
find it out. So I still believe it's a good solution.

Also there could be a RTFM status for issues, and you just change the 
status to RTFM and link to http://drupal.org/project/tinymce/faq or 
http://drupal.org/project/tinymce/manual (to implement those aliases 
into project module might actually be a good idea)

> 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 

This one is the most work, and takes more resources, but it's not that 
much different from option 1.


Lodewijk Evers
Ontwerpwerk