Can you set up a cron job to auto-update QMO stage? That way stuff on trunk can make it there without an IT bug. Here's the URL: https://quality-new.stage.mozilla.com/
Mike, Can you elaborate? QMO = WP install. The content folders are already auto-updated from : [root@mrapp-stage02 qmo_content]# svn info Path: . URL: http://svn.mozilla.org/projects/quality.mozilla.org/branches/wordpress/wp-content Repository Root: http://svn.mozilla.org Repository UUID: 4eb1ac78-321c-0410-a911-ec516a8615a5 Revision: 83186 Node Kind: directory Schedule: normal Last Changed Author: firstname.lastname@example.org Last Changed Rev: 83119 Last Changed Date: 2011-02-23 13:38:55 -0800 (Wed, 23 Feb 2011) What else needs to be auto-updated?
Hmm...I guess the issue then is that when things are rolled out, such as Wordpress changes on Mozilla properties, they don't get mirrored on the staging site. The wordpress version is different and I'm prompted, even though I'm an admin on the WP instance on the staging site, for a root password if I try to upgrade. I've seen theme differences in the past as well, which made me think that things weren't being updated often. There should be no difference, except the contents of the DB for posts, pages, and users, between the staging site and the live site and there are differences right now. I want to be able to test proposed changes, such as plugin updates, on the staging site before they get rolled to the live site. How often does the staging site get a synch from SVN?
Every 5 mins. The wordpress instance itself - now that's a different story. That's not on auto sync (can't be on auto sync). So if you see a new release and haven't seen the stage site being upgraded, please file a bug? and we'll upgrade it for you. Do you want to morph this into an upgrade qmo stage to 3.1 bug?
I'll file a separate bug. I actually didn't want our live site on 3.1 the day of release (since there are compatibility problems with Buddypress, which we run) but since it was done anyway, I do think we should match.
(In reply to comment #4) > I actually didn't want our live site on 3.1 the day of release (since there are > compatibility problems with Buddypress, which we run) but since it was done > anyway, I do think we should match. This specific upgrade could have been avoided/postponed, but the norm with WP releases are they're usually security fixes..and IT will roll them out to production sites with usually no notice at all. I'm going to close this bug out.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.