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

[Kevin Reynen]

Patching is fine... for developers.  Maybe I see more issues from
new-to-drupal, non-developers due to the nature of TinyMCE, but asking
users to make configuration changes to dense code they don't
understand is what generates the majority of support requests.

My goal in bringing this up was only to find a way to distribute a
version of the module that requires LESS support.  It looks like there
may be some concessions made for smaller 3rd party libraries, but not
larger ones.  Rolling larger external files into releases may be an
itch someone scratches in the future, but for now the easiest way for
me to get a better module to users that requires less support is to
distribute it outside of Drupal.org.

- Kevin Reynen

On 5/22/07, Earnie Boyd <earnie at users.sourceforge.net> wrote:
> Quoting Kevin Reynen <kreynen at gmail.com>:
>
> > Some people seem to have missed this point...
> >
>
> Not I.
>
> > I want to CHANGE the configuration of TinyMCE from Moxiecode's default
> > configuration to eliminate the double filter issues for Drupal users.
> >
> > but if 3rd party libraries are
> > never going to be rolled into Drupal releases through CVS or some
> > other method, what do you suggest?
> >
>
> * Store the patches into CVS.  * The install/upgrade process downloads
> the TinyMCE tarball version for the patch set created and applys the
> patch.
> * Issues for Windows users.
>   ** There exists gnu patch ports for windows
>   ** Instruct those users to have the patch program in PATH.
> * Issues with already patched set
>   ** How to handle the patch errors?
>   ** How to determine current state of installed library?
>
> IMO storing the modified library as part of the module is what should happen.
>
> Earnie
>