[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
ontwerpwerk at webcommunicatie.org
Tue May 22 17:15:27 UTC 2007
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
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.
More information about the development