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

Derek Wright drupal at dwwright.net
Tue May 22 16:27:51 UTC 2007

(sorry if this shows up twice, but i was having some email problems  
yesterday when i tried to send it.  i still didn't get a copy from  
the list, and recent traffic on the list makes me think no one else  
did, either.)

On May 21, 2007, at 12:56 PM, Johan Forngren wrote:

> Is it possible to do some packaging/tagging magic? Have one ready- 
> to-go and one almost-ready-to-go release?

no.  i don't think it's a good idea to have our packaging script  
downloading/checking out source from remote repositories and  
packaging that with drupal code to create contrib release tarballs:

1) big security concerns:
- how to securely fetch the sources we think we're fetching
- how module maintainers specify what to download and where to put it  
in such a way that they don't effectively have access to a php filter  
on drupal.org, etc.

2) majorly complicates the packaging script:
- you *know* some 3rd party libraries are going to live in SVN, git,  
etc, etc, so we'd need to handle client code for each kind of  
revision control system people would want to fetch from.
- more potential for blocking operations, needing to timeout, etc.
- what about the load of doing this for development snapshots every  
12 hours?  we'd probably need to do some crazy throttle crap, perhaps  
cache locally the copies we check out, etc, etc.

3) doesn't actually solve one of the main objections to putting the  
3rd party code directly into our repo: maintainers would have to  
specify an exact version to fetch (a CVS/SVN tag to checkout from,  
etc), and that's basically just as likely to be stale as if they  
manually imported the libs themselves.

if i kept thinking about it, i'm sure i could come up with other  
reasons not to do this, but the above would be enough justification  
for me to "won't fix" any issue that showed up in the queue proposing  


p.s. other people are more than welcome to help with maintaining/ 
improving the packaging script.  since the new release system, it's  
no longer some top-secret thing that only people with shell access on  
d.o could even see.  now, the script we use on d.o is included in  
contrib[1] as an example for anyone else to locally modify for their  
own installation of project_release.module.  so, if you want to help,  
you don't have to become a d.o infra maintainer, just checkout from  
CVS, roll a patch, and submit[2] it.  don't have a good test site to  
try out your changes?  download the drupal.org testing install profile 
[3] and use that.  there's not yet a dummy CVS repository all setup  
for the example projects that are created programatically, so the  
first step is you could help with that[4].  thanks.

[1] contributions/modules/project/release/package-release-nodes.php
[2] http://drupal.org/node/add/project-issue/project (component:  
[3] http://drupal.org/project/drupalorg_testing
[4] http://drupal.org/node/144429

More information about the development mailing list