Posted by justintime on June 2, 2011 at 4:08pm
The group doesn't lend itself well to supporting the StackScript, and I needed to use VCS to keep track of changes to the script. I was going to use Github, but their issue tracker sucks. I won't actually be releasing any files, so I didn't want to create a full-blown project, so I setup a sandbox project to host the source code for the script and to track issues with it:
http://drupal.org/sandbox/justintime/1176768
I do have permissions to create new projects on d.o, so if enough people say they want http://drupal.org/project/mercury_stackscript, I'll promote it to a full project.
Categories: mercury pantheon linode stackscript, Documentation
Comments
Not sure I understand
I'm a Mercury user, but installed using the 1.2 pre-beta that included a lot of extra Pantheon stuff I didn't need. I'd like to use the stackscript. But isn't that just a matter of choosing the stackscript on Linode when initializing a server?
I'm unfamiliar with Drupal's project and sandbox interface, or git. Having a full blow project would be nice for us "newbies." But can you explain how that would differ from just using the Linode stackscript?
The project is for managing the development of the script
+1 for making the stackscript a full project
The benefit of the stackscript being a project is that there is an issue queue to manage the development of the project. This group forum does not work well for keeping track of changes/requests/bugs etc. The Drupal project doesn't affect your use of the script, it's just a tool to manage the development of the script.
small world
Hey Andrew -- remember me from DrupalCon at the dev/stg/prod BoF? :)
I sure do
Funny you should mention that. I was just commenting with my coworker that I thought I had met you at DrupalCon :-)
For support only
Yep!
It doesn't change the process in which you use the stackscript at all. You just select it on Linode's site.
The biggest problem is that there's no way for someone to tell me about a problem they had with the script except to add a post to this group. That's both borderline off-topic, and hard to track. So, using a Drupal sandbox project gives us all an issue queue to use for any support requests or bugs.
Also, Linode doesn't provide a git repository so that those so inclined can really see what's changing in the script. A Drupal sandbox project gives me a git repo so that people can see what's going on, and easily submit patches back.
Good questions, sorry I didn't address them in the initial post.
Many thanks
That's just the clarification I needed. I can't wait to try out the new script.
+1 for Project
Would love to see this as a project on d.o.
+1 for project on d.o
+1 for project on d.o
Hadi Farnoud
فروشگاه ساز | ایمیل مارکتینگ پاکت
+1
+1
+1 for project! Also, is the
+1 for project!
Also, is the current linode stackscript up-to-date with your latest changes?
Cheers,
David
+1 for Project
YAPB (yet another project benefit): Continuity. Should you move on, abandon the script or, god forbid, get hit by a truck, another maintainer may well step forward and pick up the baton.
Haven't tried Mercury yet, but I'm seriously looking at it.
Any tips on guestimating the Linode RAM requirements for a Drupal site? Linode's 512MB RAM has plenty of storage and transfer for my needs, but my site(s) does(do) use quite a few modules, including some big ones like CiviCRM. My current php memory_limit is 160MB, which works well, but at memory_limit = 96MB it throws some 'out of memory' errors from time to time. Maybe I should just spin up a Linode and see.
Another +1
I would love to see this as a project. Great work on the stackscript!