[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
this.
-derek
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:
"Releases")
[3] http://drupal.org/project/drupalorg_testing
[4] http://drupal.org/node/144429
More information about the development
mailing list