Closed Bug 1382705 Opened 2 years ago Closed 2 years ago

Pref off MOZ_PHOTON_PREFERENCES for Fx56

Categories

(Firefox :: Preferences, enhancement, P1)

enhancement

Tracking

()

RESOLVED WONTFIX
Firefox 57

People

(Reporter: rickychien, Assigned: rickychien)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

No description provided.
Comment on attachment 8888357 [details]
Bug 1382705 - Pref off MOZ_PHOTON_PREFERENCES for Fx56

https://reviewboard.mozilla.org/r/159302/#review164722

I'm going to hold off on reviewing this. I don't think we should be disabling one Photon flag to help QA test official Nightly builds. If we only disable one flag, then we have Nightly in an odd mis-matched state where almost all Photon flags are enabled except for this one, which we never expect to ship like this.

Either this patch should disable all flags or QA should be comfortable testing Cedar builds. Perhaps we disable all flags on Nightly 3-4 days before the merge, but disabling just one seems odd. I think we would potentially run in to bugs that only exist based on some combination of enabled/disabled flags and these bugs would be unhelpful and confusing.
Attachment #8888357 - Flags: review?(jaws) → review-
Here is the details [1] explaining our purpose and QA is unable to do test plan sign-off for Cedar branch since it's not an official Nightly build for normal users. 

I think there are some misunderstandings. For preferences, we're not fully focusing on shipping visual redesign features during feature complete cycles from 55 ~ 57. We've other non-visual redesign features will be shipped in Fx56 such as search and re-org v2, so both of them require QA verification and features should be enabled by default in Fx56.

As you may know, some Photon teams might fully focus on shipping visual redesign feature that starts from 55 ~ 57. So the landing strategy they're currently adopting is to introduce a build-time flag to enable the visual redesign feature by default on Nightly but pref off on Beta and Release. This approach might work well since QA can start verifying the redesign without confused. 

However, it would be confused for preferences. Before the merge day (8/2), QA will start testing and sign-off for Fx56 (Search + Reorg V2) but developers can also deliver features for Fx57 in the same time. It would introduce mixing features (56 + 57) during this time period if we don't disable visual redesign in Nightly, and then QA might get confused while verifying because there would be many new Fx57 UI changes happening on latest Nightly but it doesn't match the 56 spec.

Marco, do you know how many Photon teams could run into this kind of problem? Or maybe it's just us? I'd like to let you know our circumstance so you could do me a favor to inform the rest of the teams.

> Perhaps we disable all flags on Nightly 3-4 days before the merge, but disabling just one seems odd

Jared, there are remaining 7 days and then all flags will be disabled. I don't think it's a necessary and worth doing task to get all Photon teams's approved to disable the flag.

I'd suggest that we can hold on and then land Fx57 features after 8/2 merge day.

We can close this bug if you think that makes sense to you.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1357306#c13
Flags: needinfo?(mmucci)
Flags: needinfo?(jaws)
Thanks for the write-up. I agree with your conclusion, especially since I haven't seen any patches for the visual redesign yet (maybe someone else review them?), so if there is nothing to land right away then we might as well wait until after merge day. Sorry for stretching this discussion for so long.
Flags: needinfo?(jaws)
According to comment 3 and comment 4, I think we had a consensus of opinion for holding all visual redesign bugs until merge day. 

Pref off MOZ_PHOTON_PREFERENCES flag is unnecessary in this time, so let's close this bug.
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
remove whiteboard tag due to it's WONTFIX
Whiteboard: [photon-preference][triage]
Flags: needinfo?(mmucci)
You need to log in before you can comment on or make changes to this bug.