569947 - Update Paris Office address on Contact page

Status: VERIFIED FIXED

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

Description

[Pascal Chevrel:pascalc]

Mozilla has a new office in Paris, the address and google map coordinate need to be updated, i'll do that shortly.

Comment 1

[Pascal Chevrel:pascalc]

address fixed in r68276 and longitude/lattitude in r68280, marking fixed.

Comment 2

[raymond [:retornam] (inactive)]

verified fixed on https://www-trunk.stage.mozilla.com/en-US/about/contact


28 boulevard Poissonnière
75009 Paris, France

Comment 4

[John Slater]

Just pushed the files thru Kubla. For future reference, let's not verify a bug fixed based on it being on trunk...it needs to be live first.

Resetting status to "resolved fixed"...if someone could verify once it's live that'd be great.

Comment 5

[Alex Buchanan [:abuchanan]]

(In reply to comment #4)
> Just pushed the files thru Kubla. For future reference, let's not verify a bug
> fixed based on it being on trunk...it needs to be live first.

Verifying on stage is normal workflow for all our projects, since for most projects, we need to know that QA has checked the fix before we launch that fix.

However, I understand that mozilla.com is a sort of different animal and we need some status that says "this is live in production" and/or "this is verified in production"

Comment 6

[John Slater]

Yeah, mozilla.com is definitely different...something being complete on stage isn't the same thing as it being live.

Rather than changing bugzilla, can't we just agree to make an exception here to verify once the changes are live? That's how we've typically done it.

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

Adding "push-needed" to a verified fixed (on trunk/stage) bug seems pretty clear to me; perhaps you could run a query to know what to push?

I agree with Alex: Mozilla.com is definitely a different beast, and we should figure out how to better manage the workflow, since it's clear that it's not working for everyone.

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

John: what do you propose to make it clear that changes have passed QA, at a glance, since you no longer are comfortable with having Verified FIXED stand for that?

Comment 9

[John Slater]

I'm pretty sure that for mozilla.com we usually just mark as resolved: fixed when it's passed QA and then verified: fixed when it's live. That's my memory of the process over the last few years...as far as I'm concerned, nothing has changed on my end regarding comfort level or anything else.

Comment 10

[Alex Buchanan [:abuchanan]]

I've never seen it done that way.  In my experience, the developer marks it fixed, signaling QA, who marks it verified.  I prefer to have fixes verified on stage, so that we don't push potentially broken things to production.

Could you elaborate on the problem with verifying on stage?  I thought push-needed was the solution to marking things that aren't in production yet.

Comment 11

[John Slater]

This is a non issue...whatever you guys want is fine. Sorry I brought it up.

Comment 12

[Michael Morgan [:morgamic]]

We should talk about it and define the process to set clear expectations for next time.  Someone want to tackle this?

Comment 13

[Alex Buchanan [:abuchanan]]

Talked to Donner, he agrees we need to verify on both stage and production.  What we need is a way to signify this in bugzilla.  I propose we start using some flags.

push-needed could be a flag, and verified-production too.

What do you think?

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #13)
> Talked to Donner, he agrees we need to verify on both stage and production. 
> What we need is a way to signify this in bugzilla.  I propose we start using
> some flags.
> 
> push-needed could be a flag, and verified-production too.
> 
> What do you think?

I agree, and have filed bug 572466 to get those flags set up.

Verified FIXED on http://www.mozilla.com/en-US/about/contact.html, while I'm here :-)