The QA team has been working with Advomatic on the new quality.mozilla.org website. The Advomatic team is almost done with development and so will soon be ready to migrate the code onto our servers. We will need the new website to be set up with a SVN repository and accounts for myself, Jay, and the Advomatic team, so they can migrate the code. We would also need a staging site to test QMO2 until it'll be ready for prime time.
/projects/quality.mozilla.org/branches/qmo2 already exists. From my understanding, that's the branch that's supposed to be used for this new version of the site. For each person that needs access to the repo that doesn't already have an SVN account, he/she will need to file a bug under mozilla.org :: Account Request: SVN, as we'll have to get committer forms for each person. You and Jay already have access to this branch, so you two should be good to go. Once you have the initial code in svn, IT can help you set up a staging site.
Sounds good. Jay: how should we proceed on getting an account for Advomatic? Should they file the ticket or we do it for them or what?
does advomatic really need an account? can't they just give us a tarball of the code? If they really need one, I'm sure they'll have to go through the SVN account registration process with Marcia like everyone. http://svn.mozilla.org/projects/quality.mozilla.org/branches/qmo2/ is a directory for the code get the code in and give IT some set up instructions and we can get a stage site pulling from the above branch
We will need the all the code in svn, but they don't have to put it there.
Can this bug be closed now? or is there anything left for IT to do?
(In reply to comment #3) > does advomatic really need an account? can't they just give us a tarball of > the code? They don't really need an account, but I figured it would easier for them to control the checkins since they are still developing the site on their end. I just wanted to get what they have hosted here so we can start playing around with it and get content in there while they wrap things up. They will most likely be merging/checking in changes frequently over the next month of so. If it's easier to just get tarballs from them and have someone her check it in, that works for me. I just don't want to be managing the svn checkins... but will if I have to.
(In reply to comment #5) > Can this bug be closed now? or is there anything left for IT to do? > I would rather leave this open until we have the latest qmo2 checked in and ready for staging... at which point you guys can get the new site up somewhere. I'm updating the summary... feel free to reassign temporarily if you want this off some IT queue.
Summary: Set up new SVN repository for upcoming quality.mozilla.org → Set up new SVN repository (done), checkin Advomatic code and stage QMO2 at quality.new.mozilla.org (or whatever staging URL we need to use)
Assignee: server-ops → nobody
Component: Server Operations → quality.mozilla.org
Product: mozilla.org → Websites
QA Contact: mrz → quality-mozilla-org
Target Milestone: --- → 2.0
Reed helped me get the code checked into SVN: http://viewvc.svn.mozilla.org/vc/projects/quality.mozilla.org/branches/qmo2/ And I have the mysql dump available here: http://people.mozilla.com/~jpatel/qmo/advomatic/mozilla-2008-08-26.mysql I'm assuming there will be some db related changes required in the code and the mysql will need to be imported to our db server... so hopefully IT and webdev can work that out. Reassinging to Aravind. Aravind: Can you work with Alex or Oremj to get this thing staged? Thanks!
Assignee: jay → aravind
Summary: Set up new SVN repository (done), checkin Advomatic code and stage QMO2 at quality.new.mozilla.org (or whatever staging URL we need to use) → Set up new SVN repository (done), checkin Advomatic code (done) and stage QMO2 at quality.new.mozilla.org (or whatever staging URL we need to use)
Assignee: aravind → server-ops
Component: quality.mozilla.org → Server Operations
Product: Websites → mozilla.org
QA Contact: quality-mozilla-org → mrz
Target Milestone: 2.0 → ---
upping the severity to critical as we need the site up and running by tomorrow or early thursday for a demo/brownbag. please help us get this done quickly. thanks!
Severity: normal → critical
Seeing this on install: * user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM q_menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in /data/www/quality.mozilla.org/includes/menu.inc on line 315. * user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM q_menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in /data/www/quality.mozilla.org/includes/menu.inc on line 315.
Whiteboard: SQL Errors on install
I tried to set this up on khan, and I get PHP Fatal error: Call to undefined function timezone_open() in /home/abuchanan/public_html/qmo2/sites/all/modules/date/date_api.module on line 565 Looks like this functions isn't enable by default until php 5.2.0, khan runs 5.1.6. just an FYI. which version is the cluster running? will khan be updated by IT? I'll try to set this up on my local machine for now.
Cluster is 5.1.6. 5.2, or newer, probably won't be available from redhat for another year or so.
Advomatic's staging server is using PHP 5.2.0-8+etch10. The Date API module, which we're using for events, requires PHP 5.2. There are PHP 4 emulations, which we could use instead, although it may have some performance degradation, according to http://drupal.org/project/date.
Are you still getting the MYSQL error? That's odd. Can you give more information? Is it during installation? After installation but on a specific page? A quick search on Google tells me others are having similar problems. If this bug can be reproduced, we might try one of the solutions outlined at http://drupal.org/node/247360 and file an issue with the Drupal project.
Also, what's your MySQL version? The staging server is using 5.0.32.
mysql --version mysql Ver 14.12 Distrib 5.0.45, for redhat-linux-gnu (x86_64) using readline 5.0 (In reply to comment #13) > Advomatic's staging server is using PHP 5.2.0-8+etch10. The Date API module, > which we're using for events, requires PHP 5.2. There are PHP 4 emulations, > which we could use instead, although it may have some performance degradation, > according to http://drupal.org/project/date. > We won't be running PHP 5.2 until Redhat offically supports it. (In reply to comment #14) > Are you still getting the MYSQL error? That's odd. Can you give more > information? Is it during installation? After installation but on a specific > page? > I filled in the database information during the install the errors showed up immediately after.
Aaron: Anything to add here? Not sure if you've been in contact with Jeremy, but hopefully you guys can work together to get this thing fixed. Jeremy: Let me know if you need help getting a hold of any of the Advomatic guys (I'm not sure how often they'll be looking for our "bug mail"... but they are responsive to their grouphub messages)
I wonder if you're still getting those original MySQL errors? Seems like maybe not, if you're getting PHP errors now. To fix the PHP errors, you'll need to go to /admin/build/modules and enable the Date PHP4 module in the Date/Time field set. I've done this on Advomatic's staging, if you would rather reload the database.
I still can't my copy past the install ( same mysql errors ). Can I provide you with anymore information?
hold on -- if you're building the site from a db dump, you shouldn't have to go through the installation process. in fact, you would simply get a message from install.php telling you the site was already installed. what specific steps are you taking to reproduce this error?
I didn't see the part about a db dump :-( Doing that...
Okay, now I am to the point where I see: PHP Fatal error: Call to undefined function timezone_open() in sites/all/modules/date/date_api.module on line 565. /admin/build/module fatal errors as well, so I can't make the change from there.
Staging site it is up at quality.stage.mozilla.com.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
sweet! sorry oremj, i didn't realize you were trying to install from scratch. glad to see it is up. just to clarify, our staged site is exactly like mozilla.advomatic.com... minus any changes since yesterday. right aaron/oremj?
looks good to me. i can make any future required db changes from the administration screens there now. however, i did add some files to the repository today (specifically /sites/all/modules/flag and /sites/all/modules/imageapi), if we can get a new svn dump soon. (they'll be needed as i complete the community pages.) thanks, aaron
oremj: i'm marking this r.fixed, BUT can you put the site under http auth? it's a marketing requirement to not have the site publicly accessible until it's ready. thanks! aaron: please use the advomatic grouphub to tell me when to update the svn dump and i can do that before you go in to make any db/admin changes at quality.stage.mozilla.com. thanks for your help!
Reopening so oremj can put the site behind http auth. We can't have it publicly viewable due to marketing rules. Please get that protected asap! username/pw doesn't matter.. just make it easy to remember. :-) Thanks! - Jay
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
In that case I have moved the site to https://quality.authstage.mozilla.com/. Use your LDAP username/password.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 10 years ago
Resolution: --- → FIXED
Thanks Jeremy! Moving it to authstage actually fixed some weird problems we were having logging into the site. However, now the Advomatic guys don't have access to the site. What do you suggest we do to allow them to work on the site while it's behind the firewall?
Probably easiest thing would be to set up a generic username and password. Sound good?
I've also faxed a signed committer's agreement.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.