Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
(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
participants (1)
-
Derek Wright