- Development - lists.drupal.org

Re: [development] Drupal's CVS policies... including 'foriegn' code
by Matt Farina 22 May '07

22 May '07

1 0

Justifications
by Steven Peck 22 May '07

22 May '07

I don't normally do this but I feel moved to on this occasion. Sometimes people try and justify their argument by saying they heard something isn't done because some mysterious 'others hate' something. Please don't do this. Just because you 'heard' something does not mean it's true. It is also NOT a reason to justify your attempt to change something. There are other/better ways to marshal your arguments in favor of change and it automatically makes the rest of your justification weaker. Managing an Enterprise infrastructure is more complex and diverse then "it's not done because someone hates something". If it's time to review or change something, then it should be done on it's _own merits_ with a full understanding of the reasons the policy exists in the first place, _not_ with accusations or rumors claimed as fact. ------------- It's easy enough to have a _vision_ of the future, but sometimes people have more _visions_ then time or people to implement. If people give you tools or rights to accomplish one of your visions, then you have more credibility if you actually start or complete it for getting people rallied around your next _vision_. Regards, Steven Peck http://www.blkmtn.org/what-is-a-drupal-user

2 1

Fwd: Re: Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
by Larry Garfield 22 May '07

22 May '07

I think this was supposed to go here... ---------- Forwarded Message ---------- Subject: Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module? Date: Monday 21 May 2007 From: "Kevin Reynen" <kreynen(a)gmail.com> To: larry(a)garfieldtech.com I thought about that, but how would the module know the path to the current version of TinyMCE Moxiecode has released... or if that's compatible with the module version/Drupal version/ theme? I could maintain a pointer to that path somewhere building in an additional dependency and potential security risk. Instead of inserting suspect code into Drupal's CVS... hijack the location gettinmymce.php returns and install any code you'd like? Have you looked at the install/maintainence process SMF uses (http://www.simplemachines.org/) It's really slick, but it only pulls from their CVS/SVN? which I think is the only way to make that type of install secure. I think the Update Status module (http://drupal.org/project/update_status) should eventually incorporate SMF-like installs, but since Nedjo Rogers maintains Update Status AND contributes to TinyMCE... my guess is if there was a secure, reliable way to install Moxie's latest release that way or update Drupal modules from the CVS, he'd already be doing it. - Kevin On 5/21/07, Larry Garfield <larry(a)garfieldtech.com> wrote: > > Is this something that could be handled technologically? The balloon-CVS argument for foreign code is valid, IMO, but so is modules that rely on foreign code being too hard to install currently. > > I know we can't install extra code via the UI for security reasons, but would it be possible to include a small shell PHP script with the TinyMCE module that would download the latest TinyMCE from moxie, untar it, and put it where it belongs? The install hook for the module could then have a drupal_set_message() "Module installed, please remember to run gettinmymce.php from the command line" or something like that. It's similar to the way some Linux distros handle non-free media codecs. Something that wouldn't require reading the README file to figure out. > > Possible? Reasonable? (Two separate questions. <g>) > > --Larry Garfield > > On Mon, 21 May 2007 14:38:58 -0400, Andre Molnar <mcsparkerton(a)yahoo.co.uk> wrote: > > Kevin Reynen wrote: > > <snip> > > > > I think the issue has little to do with hatred of WYSIWYG. > > As I understand it, the problem is that it would set a bad precedent for > > CVS usage. > > > > Lets take the case of module foo that is simple small lightweight > > interface between Drupal and some massive external library. With the > > current rules module foo is only 10K in CVS. If module foo included the > > external library as well - foo suddenly grows to 300K. > > > > But foo is really important to people - and people really like foo and > > people complain about foo's install process (having to separately > > download the external library). So an exception is made for foo... > > > > Then along comes module bar - just as important and just as popular and > > another exception is made.... then along comes module baz. > > > > Baz may or may not be important or well loved - but the maintainer says > > "Why you picking on module baz when foo and bar get to include their > > external libraries?" > > > > --- > > Solution? > > On the project page you can always include a link to a fully packaged > > TinyMCE module hosted elsewhere. The only thing is that you would have > > to maintain your own packaging. > > > > andre > > (a person who would love to have tinymce pre-packaged but understands > > completely why it shouldn't be that way) > > ------------------------------------------------------- -- Larry Garfield AIM: LOLG42 larry(a)garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

2 1

Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
by Derek Wright 22 May '07

22 May '07

(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

1 0

Re: [development] Drupal's CVS policies... including 'foriegn' code
by Peter Wolanin 21 May '07

21 May '07

There was a serious discussion in the forum about this a few weeks ago: http://drupal.org/node/124978 I think this post and its comments are worth reading before posting more to the list. -Peter

1 0

Time off
by Darren Oh 21 May '07

21 May '07

So you know what's going on, I am putting my Drupal work on hold until mid-August, 2007. I will be available for further Drupal work after that date.

1 0

Download statistics for April
by Greg Knaddison - GVS 21 May '07

21 May '07

Here's another review of download statistics (following my analysis from October[1] and January[2]. After Dries pretty analysis[3] now you get my ugly analysis ;) Top 20 modules: Rank Project Downloads 1 views 8,826 2 image 6,959 3 cck 6,801 4 tinymce 5,616 5 event 3,300 6 date 3,034 7 img_assist 2,834 8 gallery 2,819 9 pathauto 2,744 10 gsitemap 2,647 11 ecommerce 2,632 12 imce 2,618 13 fckeditor 2,422 14 calendar 2,369 15 widgeditor 2,280 16 acidfree 2,107 17 imagefield 2,096 18 contemplate 2,056 19 captcha 1,988 20 update_status 1,983 The raw data is in my sandbox [4] in both OpenOffice.org spreadsheet format and in csv. More verbose analysis on this and other topics is on my site [5]. Regards, Greg [1] http://knaddison.com/drupal/drupal-download-statistics-for-october [2] http://knaddison.com/drupal/january-drupal-download-statistics [3] http://buytaert.net/drupal-download-statistics-2007 [4] http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/greggles/ [5] http://knaddison.com/drupal/drupal-download-statistics-april-2007

1 0

Where should we call drupal_add_js?
by Fernando Silva 21 May '07

21 May '07

Hi everyone, Assuming that we want to reduce the size of JavaScript transfered to the client we have some options: * always call drupal_add_js() in hook_menu() because it will be download only once to the entire site? * is there other place where we can call drupal_add_js() in a global way? hook_init() probably not because it does not get executed with "aggressive cache" I think... * only call drupal_add_js() when we are going to use some of it, in the current page? Regards, Fernando Silva

3 5

Amazing patches in the queue
by Karoly Negyesi 21 May '07

21 May '07

Hi, Here I sit totally smitten, there are so many great patches right on the top of the issue queue. Four of my favorites: http://drupal.org/node/113435 Data API: first steps http://drupal.org/node/144765 Schema API 1 http://drupal.org/node/140218 Make Drupal smaller http://drupal.org/node/145551 Enable dynamic page loading and rendering into different formats (JSON, XML) These four --without a doubt-- opens a new chapter in our loved Drupal's life. Chime in -- it's your future we are shaping here! Regards, NK

1 0

documented custom_url_rewrite
by Karoly Negyesi 21 May '07

21 May '07

Hi, I just committed documentation to custom_url_rewrite , it's a not too well known extremely powerful function. Example usages documented: static aliases to dynamic paths, changing 'node' to 'article', overwriting already defined menu paths . Regards, NK

4 4