Closed Bug 592685 Opened 15 years ago Closed 15 years ago

Add Beta Promo to 3.6.13 What's New Page

Categories

(www.mozilla.org :: General, defect, P1)

Product:
www.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: lmesa, Assigned: abuchanan)

References

Details

Please add the following promo to the 3.6.10 WN page for en-US page. We will test and add the promo to other locales depending on results. 40% of users should see another promo, 30% should see promo 1, 30% should see promo 2 (promos 1 & 2 are in the linked PSDs).
Assignee: nobody → steven
I have the PSD for promo 1 here: https://www.yousendit.com/download/UFVyaXREQ0NqY28wTVE9PQ Promo 2 should be coming shortly.
And sorry, it should be 3.6.9--thanks Pascal.
Summary: Add Beta Promo to 3.6.10 What's New Page → Add Beta Promo to 3.6.9 What's New Page
Here is the file--Look under Whats New. Both promos are layered within the file. http://people.mozilla.org/~lmesa/Firefox%204%20Beta%20Campaign/
Sorry, changing this to 3.6.10 whats new page--not as ready for the mass push as we thought.
Summary: Add Beta Promo to 3.6.9 What's New Page → Add Beta Promo to 3.6.10 What's New Page
does that mean that the whatrsnew promos for locales are also pushed back to 3.6.10?
What is the status here? Is the promo built? If so, it would be great for this to go live around 28/29 of November.
(In reply to comment #6) > What is the status here? Is the promo built? If so, it would be great for this > to go live around 28/29 of November. Looks like development hasn't started on this yet. Steven, can you guys take this one without derailing the site redesign?
This is done in trunk in r77611. The whatsnew pages are shared, so this is on 3.6.10, 3.6.11, 3.6.12 whatsnew pages, etc.
Keywords: qawanted
Both promo images appear alright but both do not link to anything
Keywords: qawanted
(In reply to comment #9) > Both promo images appear alright but both do not link to anything Oops, fixed in trunk in r77624. Thanks.
Keywords: qawanted
Whiteboard: [ms-11/18]
Hi all, This looks great. Because of some recent crashiness on the beta, we're going to wait on pushing this live until 3.6.13 scheduled for Dec 9th. Pascal, this includes promos for other locales too. I'm assigning to legneato to make sure this goes into his launch plan for 3.6.13.
Assignee: steven → clegnitto
Target Milestone: 4.0 → 3.6
Whiteboard: [ms-11/18]
Summary: Add Beta Promo to 3.6.10 What's New Page → Add Beta Promo to 3.6.13 What's New Page
laura, you mean that we are waiting for beta 8 to promote the beta right?
(In reply to comment #13) > laura, you mean that we are waiting for beta 8 to promote the beta right? Yes, correct.
Blocks: 617801
(In reply to comment #14) > (In reply to comment #13) > > laura, you mean that we are waiting for beta 8 to promote the beta right? > > Yes, correct. Because 3.6.13 is going now, and at the time we thought beta 8 would hit before 3.6.13, I ask that we push the promo live now.
Are the link urls supposed to have /cdn in them? This looks fine on trunk (http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/whatsnew/) but /cdn links fail to load on stage (https://www.authstage.mozilla.com/en-US/firefox/3.6/whatsnew/). Is this expected? I'm worried about pushing to production w/o confirmation that the /cdn links will work when pushed there.
Also, the corner borders don't look crisp to me (won't stop the production push, just an observation)
I have another breaking request, per cbeard: can we strip all the rotating promos out of the What's New page except for the new beta one and Firefox Live? That would mean nixing Spread the Word, Tbird 3 and Rock Your Firefox. If this isn't possible before the page goes live, I'll file a bug to do it after, but it would be great to take care of it all in one swoop.
http://viewvc.svn.mozilla.org/vc?view=revision&revision=79060 leaves just the beta and live ones in
Thanks Christian!
On second thought, it's in version control so yanking them out rather than commenting out: http://viewvc.svn.mozilla.org/vc?view=revision&revision=79062
Whoops, that last change is incomplete. Looks like it is hard-coded in js too (dunno why it doesn't just use whatever elements are in the div. I'll fix the js.
I'm guessing the images weren't pushed to stage. Checking on that.
Hmmm, I thought I did. Looks like my script didn't grab them, whoops. I'll push and if everything looks good push live.
Seems to work now, oremj tweaked authstage so /cdn works.
I pushed this to production: http://viewvc.svn.mozilla.org/vc?view=revision&revision=79073 Looks like the css changes were already pushed previously: $ diff web_trunk_mozilla.com/style/firefox/3.6/firstrun-page.css web_production_mozilla.com/style/firefox/3.6/firstrun-page.css $ svn status web_production_mozilla.com/style/firefox/3.6/firstrun-page.css $ It's been an hour and I don't see the changes live though...
(In reply to comment #28) > It's been an hour and I don't see the changes live though... Fwiw, I'm not seeing them either.
Assignee: clegnitto → server-ops
Component: www.mozilla.com → Server Operations: Web Content Push
Product: Websites → mozilla.org
QA Contact: www-mozilla-com → mrz
Target Milestone: 3.6 → ---
Version: unspecified → other
Over to server-ops. Perhaps they can tell us what is going on...
I'm going to up the priority because this was meant to go live today...
Severity: normal → major
Now I am getting an internal server error, though on stage and trunk the pages doesn't. Upping priority yet again, as this page is shown after updates and we just released some today.
Severity: major → blocker
Assignee: server-ops → jeremy.orem+bugs
buchanan figured it out. The page as checked in here used a function that isn't available on production. We're rolling back.
(still don't know why it took 1 hour + for the changes to show up originally though).
Assignee: jeremy.orem+bugs → nobody
Component: Server Operations: Web Content Push → www.mozilla.com
Product: mozilla.org → Websites
QA Contact: mrz → www-mozilla-com
Assignee: nobody → steven
We were just about to comment that /includes/min/inline.php appears to be missing in production. Sounds like you're on top of it.
Can someone else take this bug--Steven won't be able to push until tomorrow, or at least I dont think so because he's not online...
(In reply to comment #36) > Can someone else take this bug--Steven won't be able to push until tomorrow, or > at least I dont think so because he's not online... Seconded. Also, Steven can't push pages live anyway...he can make the fix (tomorrow), but someone else would still have to push it.
Assignee: steven → abuchanan
r79082 on production
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Oops, I just read comment #18 and realized that when I fixed this, I missed that. Filed a new bug for that, bug 618192 Lessons learned: It's a good habit to test your merge on a dev. site before committing to production. We have a ton of changes going into trunk these days. You can never be sure that merging an entire file will be safe, grabbing only the changes you're expecting. Cherrypicking revisions is helpful. Of course, these are symptoms of larger issues with the amount of changes we have going into mozilla.com and the way we manage them in version control. At some point (hopefully soon) we need to improve that process and relieve these headaches. If you're requesting something new after the bug has been checked by QA, file a new bug. Also, don't request late breaking changes the day of launch.
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.