We need to push out 1.0.3 just to get bug 489910 into production so the nightlies don't break (see also bug 489245 which I think will be in tonight's nightly). Tag coming later this afternoon.
If this is causing breakage we can push off schedule and as soon as you're ready.
It won't cause breakage until tonight's nightly build goes out - i.e. tomorrow, so we should be able to do it in the maintenance window.
Here's the tag: https://svn.mozilla.org/projects/sumo/tags/1.0/1.0.3_20090528/ After switching, you'll need to go in webroot/ and run sudo ./htaccess.sh and then dump caches as usual.
[root@mradm02 support.mozilla.com]# svn switch https://svn.mozilla.org/projects/sumo/tags/1.0/1.0.3_20090528/ U webroot/htaccess.dist Updated to revision 26526. [root@mradm02 support.mozilla.com]# cd webroot/ [root@mradm02 webroot]# sh htaccess.sh activating ./popups/.htaccess activating ./tikimovies/.htaccess activating ./files/.htaccess activating ./temp/.htaccess activating ./modules/.htaccess activating ./language_files/.htaccess activating ./templates_c/.htaccess activating ./games/.htaccess activating ./lang/.htaccess activating ./components/.htaccess activating ./pics/.htaccess activating ./db/.htaccess activating ./doc/.htaccess activating ./templates/.htaccess activating ./css/.htaccess activating ./img/.htaccess activating ./styles/.htaccess activating ./backups/.htaccess activating ./lib/fckeditor/.htaccess activating ./lib/fckeditor_tiki/.htaccess activating ./lib/.htaccess activating ./js/.htaccess activating ./.htaccess activating ./images/.htaccess activating ./whelp/.htaccess activating ./bin/.htaccess a) no templates touched, b) the only change is adding new URLs, not affecting any existing ones, so there would be nothing cached to clear.
Reopening because I (sadly) don't see this fixed on production; http://support.mozilla.com/1/firefox/3.6a1pre/Darwin/en-US/firefox-osxkey is a 404, but should redirect to http://support.mozilla.com/en-US/kb/Firefox+Help?style_mode=inproduct (likewise with /firefox-f1)
I can't verify. I would suggest two things to check: 1. The lines that should have changed are lines 63-65 of webroot/.htaccess.sh They should look like # F1/help menu detection for inproduct RewriteRule ^1/([\-a-zA-Z]+)/([\.0-9ab]+(?:pre)?)/([\-_a-zA-Z0-9]+)/([\-a-zA-Z]+)/firefox-f1(\/)?$ /$4/kb/Firefox+Help?style_mode=inproduct [R,NE] RewriteRule ^1/([\-a-zA-Z]+)/([\.0-9ab]+(?:pre)?)/([\-_a-zA-Z0-9]+)/([\-a-zA-Z]+)/firefox-osxkey\/$ /$4/kb/Firefox+Help?style_mode=inproduct [R,NE] 2. possible stuck git locks
Yeah, git locks were stuck. It was paging, and I was hoping to get one of the experts to poke at it to find out why it was stuck, but I've since given up on that and broke the lock and force-pushed, should all be up now. (Hopefully I didn't break git in the process).
Verified FIXED; I looked at the bug post git-clearing, and it worked on production.
Big thanks to Laura, Paul, Dave, and Stephen for the quick resolution so we can fix bug 489245 in RC1! Tested the URLs: http://support.mozilla.com/1/firefox/3.6a1pre/Darwin/en-US/firefox-f1 http://support.mozilla.com/1/firefox/3.6a1pre/Darwin/en-US/firefox-osxkey And they both work like a charm.