Closed Bug 1018283 Opened 10 years ago Closed 10 years ago

[Follow-up 951665] Pending visual revision and adjustments of the VR call screen when in lockscreen

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Dialer
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(feature-b2g:2.1, b2g-v2.0 wontfix, b2g-v2.1 fixed)

Status:
RESOLVED FIXED
Milestone:
2.0 S6 (18july)
Project Flags:
feature-b2g 2.1
Tracking Flags:
Tracking Status
b2g-v2.0 --- wontfix
b2g-v2.1 --- fixed

People

(Reporter: oteo, Assigned: gtorodelvalle)

References

Details

(Whiteboard: [in-sprint=v2.0-S5][planned-sprint])

Attachments

(17 files, 1 obsolete file)

20054.html
384 bytes, text/html
etienne
: review+
rik
: review+
rik
: feedback+
Details
call-lock.png
100.61 KB, image/png
Details
[1.4 DSDS] Dialer v0.4.pdf
2.36 MB, application/pdf
Details
lockscreen-multi_sim.png
167.21 KB, image/png
Details
callscreen-lockscreen-multi_sim.png
129.03 KB, image/png
Details
Visual Mockup. DSDS. Lock screen incoming call. Short name
216.00 KB, image/png
Details
Visual Mockup. DSDS. Lock screen incoming call. Long name
216.38 KB, image/png
Details
Visual Spec. DSDS. Lock screen incoming call
298.19 KB, image/png
Details
callscreen-lockscreen-screenshots.pdf
769.86 KB, application/pdf
vicky
: ui-review+
Details
master_lockscreen.png
129.10 KB, image/png
Details
master_lockscreen_incoming_call.png
93.85 KB, image/png
Details
v2.0_lockscreen.png
130.40 KB, image/png
Details
v2.0_lockscreen_incoming_call.png
92.54 KB, image/png
Details
v2.0-vs-v2.0_with_patch-incoming-call-when-lock-screen-enabled.png
388.91 KB, image/png
Details
L10n hack for 2.0
1.03 KB, patch
gtorodelvalle
: feedback+
Details | Diff | Splinter Review
22297.html
384 bytes, text/html
Details
bug-1018283-incoming-call-when-lockscreen.png
96.39 KB, image/png
Details 
Callscreen refresh in bug 951606 was landed at the same time that bug 951665 "[Dialer] Call screen when in lockscreen visual refresh 2.0" in order to maintain the consistency in the Visual Refresh.

As Rick explained in Bug 951606 comment 4 the UI of the call screen in the lockscreen was not perfect yet and this bug is opened to refine the lockscreen version so that it meets the visual specs. 

Besides some inconsistencies with the work on meta Bug 950884 - [VsD Refresh] Lockscreen Visual Refresh have been detected so, we will try to clarify them and addresses in this bug too.
Blocks: dialer-visual-refres
feature-b2g: --- → 2.0
Target Milestone: --- → 2.0 S3 (6june)
Assignee: nobody → gtorodelvalle
Please let me know if you expect this to land before the end of Sprint 3 this Friday. FC is June 9. Thanks!
Hi Stephany! Yes, I am currently working on this once the patch for bug 950884 landed yesterday in master ;) I'll keep you posted.
Attached file 20054.html — 
BTW, since I am sitting next to Vicky here in Taipei, she gave me the ui-review+ on the fly... ;-)
Attachment #8434758 - Flags: review?(anthony)
Attached image call-lock.png — 
I'm seeing some alignment issues on the SIM 1. Also, SIM 2 is not readable. What's the latest spec regarding SIM display btw? I remember a discussion where we said we were only gonna display one SIM/operator on that screen.
Target Milestone: 2.0 S3 (6june) → 2.0 S4 (20june)
Flagging Victoria and Carrie to see if they can clarify.
Flags: needinfo?(vpg)
Flags: needinfo?(cawang)
Please refer to p.8. 
If there are two SIM inserted, it should list both of them on lockscreen and display the SIM that is receiving the call on the incoming call area.
In addition, I think there is an icon missing next to "SIM 2" (the incoming call icon).
Hi Vicky, can you please confirm the icon part? and also I think the location of the carrier name is not aligning to the SIM indicator.
Thanks!
Flags: needinfo?(cawang)
(In reply to Carrie Wang [:carrie] from comment #6)
> Created attachment 8437404 [details]
> [1.4 DSDS] Dialer v0.4.pdf
> 
> Please refer to p.8. 
> If there are two SIM inserted, it should list both of them on lockscreen and
> display the SIM that is receiving the call on the incoming call area.
> In addition, I think there is an icon missing next to "SIM 2" (the incoming
> call icon).
> Hi Vicky, can you please confirm the icon part? and also I think the
> location of the carrier name is not aligning to the SIM indicator.
> Thanks!

Hi Carrie,
I believe we can avoid the icon part in Lockscreen as the only possibility is an Incomming call, so there's no need of an icon indicating the direction of the call, but for sure we should include the "sim X" text.

Is this bug the right place to provide the mockups?

THanks!
Flags: needinfo?(vpg)
Need-infoing Carrie regarding comment 7 ;)
Flags: needinfo?(cawang)
(In reply to Germán Toro del Valle from comment #8)
> Need-infoing Carrie regarding comment 7 ;)

Regarding the incoming call icon in the Lockscreen, this issue was already raised in bug 1019272 and Carrie confirmed that it was not a bug and it was not necessary that icon (Bug 1019272 comment 5).
(In reply to Victoria Gerchinhoren [:vicky] from comment #7)

> 
> Is this bug the right place to provide the mockups?
> 

Victoria, you can include them here if you want but do not forget doing it also in the meta bug 950760, where all the material related to the Dialer Visual refresh has been attached.
Hi guys! I have solved (part of) the issue mentioned by Anthony (thanks! ;)) regarding the multi-SIM scenario. I'll include a couple of screenshots in a sec.
I still need the final position of the "SIM N" text in the lower panel. I'll include the needed changes as soon as I get it ;-) Thanks!

The final appearance depends also on bug 1007709 (which deals with the adaptable font size) which hopefully we'll be able to land soon :)
Yes, the incoming call icon is not necessary on lockscreen. Sorry for the false alarm! Thanks!
Flags: needinfo?(cawang)
Comment on attachment 8434758 [details]
20054.html

This looks good to me. I've left some comments in Github. The biggest thing I'd like to see is the code that displays the operator(s) information be better shared.

Once the patch is updated with the SIM changes, please ask a review to a Dialer peer and also to Greg Weng for lockscreen_slide.js (and the new shared code).
Attachment #8434758 - Flags: review?(anthony) → feedback+
Visual Mockup to show how the SIM indicator should be displayed.
Comment on attachment 8434758 [details]
20054.html

Hi guys, as suggested by Anthony I have moved to 'shared' the libraries currently shared by system and callscreen regarding showing the date, time and the information about the SIM card(s) on the lock screen and the call screen when the lock screen is enabled, these are:
  1. /shared/js/simslot.js
  2. /shared/js/simslot_manager.js
  3. /shared/js/lockscreen_connection_info_manager.js

Obviously, this update affected many other files which were already using them from their previous locations.

I also removed the modified files form xfail.list to solve any JSHint issues.

The only thing pending would be the positioning of the "SIM n" text for which Pau already provided the specs. Anyhow and since this part of the patch depends on the patch for bug 1007709, I will include it as soon as that bug's patch lands. It may only require CSS code.
Attachment #8434758 - Flags: review?(gweng)
Attachment #8434758 - Flags: review?(etienne)
Depends on: 1007709
Sadly I squashed the latest changes in the original commit reviewed by Anthony instead of including a new commit :( This is the original commit in case you want to take a look at it:  https://github.com/gtorodelvalle/gaia/commit/6bc943ce025e9ca6b07734d71f66a4a145657685
Comment on attachment 8434758 [details]
20054.html

Since I'm not intimate with CallScreen, my concerns are all about the LockScreen parts. The thing I don't understand is if you need to change the shared slider, because you can customize it in your own component, unless the default properties can't satisfy your needs.
Attachment #8434758 - Flags: review?(gweng)
Comment on attachment 8434758 [details]
20054.html

r=me for the tiny tiny part which is not Dialer nor Lockscreen.
Rik will finish the dialer part since he started and Greg should definitely do the slider part (and already did :))
Attachment #8434758 - Flags: review?(etienne)
Attachment #8434758 - Flags: review?(anthony)
Attachment #8434758 - Flags: review+
I couldn't take a look yesterday, I'll do that on Monday.
Comment on attachment 8434758 [details]
20054.html

Thanks for the huge work and the effort to move files to JSHint!
Attachment #8434758 - Flags: review?(anthony) → review+
Both Travis and Gaia-try are not very happy though so please fix this before landing.
blocking-b2g: --- → backlog
feature-b2g: 2.0 → ---
See Also: → 1030049
Target Milestone: 2.0 S4 (20june) → 2.0 S5 (4july)
Vicky, notice that I have vertically centered the "SIM n" text to the number or contact name. Not to the baseline since that would be much more complex to achieve and should be covered in 1010104 (where we will implement the baseline desired behavior). Thanks!
Attachment #8447057 - Flags: ui-review?(vpg)
Should be covered in bug 1010104 ;)
Comment on attachment 8447057 [details]
callscreen-lockscreen-screenshots.pdf

OK. The baseline is still not solved, but + for the rest.
Attachment #8447057 - Flags: ui-review?(vpg) → ui-review+
Landed in master: https://github.com/mozilla-b2g/gaia/commit/05670c059f2d4772b3557bd7bd5d88507f784b27
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
sorry had to revert this change for failing gaia unit tests like https://tbpl.mozilla.org/php/getParsedLog.php?id=43016816&tree=B2g-Inbound
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
We have to come up with some kind of solution here because they were passing locally and in Travis... :-(
I've found that it's because you requireApp('shared...') which should be 'require' in simslot_test.js, since you move the simslot from system to shared.
Hi Greg, the code seems to be right: https://github.com/mozilla-b2g/gaia/commit/05670c059f2d4772b3557bd7bd5d88507f784b27#diff-4d93e0c48d4dcfd609fdc493d21401a6L11

Anyhow, it seems to be a requireApp() vs. require() issue which does not fail locally (if no -d option is passed to gaia-test) or in Travis :-O Currently substituting the needed requireApp() appearances. Thanks!
Germán, would you like me to take a look at the test results so we can get this landed?
Whiteboard: [in-sprint=v2.0-S5]
Target Milestone: 2.0 S5 (4july) → 2.0 S6 (18july)
Whiteboard: [in-sprint=v2.0-S5] → [in-sprint=v2.0-S5][planned-sprint]
Hey Doug! Thanks, I'll ping you in IRC.

Anyhow, it seems right now master is not doing well regarding tests. See bug 1036378 and bug 1023197 :(
Looked good to land, so I went ahead with it. Thanks Germán!

https://github.com/mozilla-b2g/gaia/commit/4847968c251ebc03c3f4b5b79e884e5511018db5
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Hi guys! These are the screenshots using master and v2.0 and how the Lock Screen looks like with and without the incoming call. Just to give you some criteria to decide upon its nomination to v2.0 ;)
You'll notice the difference if you compare this screenshot to attachment 8456009 [details].
Attached file 21804.html (obsolete) — 
NOTICE THAT THIS IS A TUNED PATCH AND PULL REQUEST TO V2.0 BASED ON THE ONE LANDED IN MASTER SOLVING ALL THE ISSUES THAT A DIRECT CHERRY PICKING CAUSES.

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Bad user experience when receiving a call and having the lock screen enabled
[User impact] if declined: Bad user experience. I will include a comparison of the current implementation and the one using this patch in a forth coming comment.
[Testing completed]: Heavily tested in device
[Risk to taking this patch] (and alternatives if risky): It is less risky that its size suggests since many of the updated files are just tests which are impacted by the shifting of files to the shared folder.
[String changes made]: None
Attachment #8458051 - Flags: approval-gaia-v2.0?
In this image you can find the comparison of not applying and applying the proposed patch in v2.0. On the left hand side, you will find the lock screen and incoming call when the lock screen is enabled in the current implementation of v2.0, and on the right hand side the result with the proposed patch applied. Notice the carrier info, time info and lower slider mainly.
In the future, work like this should be broken up into more manageable chunks so that it's easier to rebase and land it over time.
Agreed :) It was my fault not asking Anthony to move the refactoring finally included in the patch we prepared for master to another bug. He suggested the refactoring, and I totally supported it, but we should have open a new bug to deal with it ;)
BTW, just mentioning that none of the issues Travis raises (the failures I mean) is related to the patch proposed for v2.0 in comment 43 ;)
Attachment #8458051 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
Looks like the v2.0 pull request needs rebasing.
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → fixed
Flags: needinfo?(gtorodelvalle)
Keywords: branch-patch-needed
Just did it, thanks! Waiting for TBPL verdict for merging ;)
Flags: needinfo?(gtorodelvalle)
Hi Ryan, TBPL is fine with landing the proposed patch (attachment 8458051 [details]) for v2.0 since the issues reported in https://tbpl.mozilla.org/?rev=99d76b823277cdfab88e45010b7e6a2345978069&tree=Gaia-Try are not related to any of the update included in this patch. Shall I directly merge the patch in v2.0 or is this anyone responsibility? :) Thanks!
Flags: needinfo?(ryanvm)
You can merge it yourself.
Flags: needinfo?(ryanvm)
Keywords: branch-patch-needed
Depends on: 1043347
(In reply to Germán Toro del Valle from comment #43)
> [String changes made]: None

Not true, sadly.

https://github.com/mozilla-b2g/gaia/pull/21804/files#diff-38 adds a string, and AFAICT, https://github.com/mozilla-b2g/gaia/pull/21804/files#diff-8d95fd61e5c07bf516c6e7fa12932402L294 uses it.

Preeti, German, how shall we proceed here?
Flags: needinfo?(praghunath)
Flags: needinfo?(gtorodelvalle)
Keywords: late-l10n
(In reply to Axel Hecht [:Pike] from comment #53)
> (In reply to Germán Toro del Valle from comment #43)
> > [String changes made]: None
> 
> Not true, sadly.
> 
> https://github.com/mozilla-b2g/gaia/pull/21804/files#diff-38 adds a string,
> and AFAICT,
> https://github.com/mozilla-b2g/gaia/pull/21804/files#diff-
> 8d95fd61e5c07bf516c6e7fa12932402L294 uses it.
> 
> Preeti, German, how shall we proceed here?

The changes in this bug are fairly massive and could have been broken apart a bit better. This one string change seems like a good candidate for being moved to another bug, so we're not blocking the rest of the changes from landing.
Comment on attachment 8458051 [details]
21804.html

Removing the approval here given there are string changes. The input provided on the approval request was wrong and till the changes are clear will not be approving.

It is very late for string changes anyway.
Attachment #8458051 - Flags: approval-gaia-v2.0+ → approval-gaia-v2.0-
Flags: needinfo?(praghunath)
The string present here is already in system[1]. Could we copy what localisers already translated? Or maybe we can change the callscreen manifest to also include system.en-US.properties?

I don't know enough about our L10N workflow to choose what's best here. Pike: Any of those solutions look feasible?

[1] https://github.com/mozilla-b2g/gaia/blob/fadfafa17f5175203b8b9457bfb95e5816f54f58/apps/system/locales/system.en-US.properties#L17
Flags: needinfo?(l10n)
(In reply to Anthony Ricaud (:rik) from comment #57)
> Or maybe we can change the callscreen manifest to also include system.en-US.properties?

This is what we did in similar situations such as bug 1030546 and bug 1032502 and it worked fairly well, though it was really ugly.
What Doug said.

Copying a string doesn't really work as many localizers work on tool chains that are two or three steps away from our repos, and don't pick up changes from there.
Flags: needinfo?(l10n)
Germán: Could you provide a patch against 2.0 that adds system.en-US.properties to the callscreen manifest? Thanks!
Flags: needinfo?(gtorodelvalle)
Given the size of system.properties and dialer.properties, I'm kind of worried about overlapping string IDs.

@stas
What happens when 2 files have strings with the same ID? In which order are they used (last overrides the first, the first is kept)?
Flags: needinfo?(stas)
(In reply to Francesco Lodolo [:flod] from comment #61)

> What happens when 2 files have strings with the same ID? In which order are
> they used (last overrides the first, the first is kept)?

The last one overrides all previous definitions.
Flags: needinfo?(stas)
(In reply to Staś Małolepszy :stas from comment #62)
> (In reply to Francesco Lodolo [:flod] from comment #61)
> The last one overrides all previous definitions.

It sounds like it's safe then to just arrange the system.***.properties files such that they're first.
(In reply to Doug Sherk (:drs) from comment #63)
> It sounds like it's safe then to just arrange the system.***.properties
> files such that they're first.

Exactly.
Germán, with any luck, it should be this simple to get it working on 2.0. Let me know if you have any problems.

Make sure that you also remove the lines you added to dialer.***.properties for the branch patch.
Attachment #8464057 - Flags: feedback?(gtorodelvalle)
(In reply to Doug Sherk (:drs) from comment #63)
> It sounds like it's safe then to just arrange the system.***.properties
> files such that they're first.

Related: we're planning to explicitly forbid duplicate strings in bug 1013831.
(In reply to Staś Małolepszy :stas from comment #66)
> (In reply to Doug Sherk (:drs) from comment #63)
> > It sounds like it's safe then to just arrange the system.***.properties
> > files such that they're first.
> 
> Related: we're planning to explicitly forbid duplicate strings in bug
> 1013831.

That's for duplicate strings in one file, in this case we're importing 2 different files in one app, so I don't think it's the same case.
(In reply to Francesco Lodolo [:flod] from comment #67)
> That's for duplicate strings in one file, in this case we're importing 2
> different files in one app, so I don't think it's the same case.

I think Staś was saying that this ordering wouldn't be a problem for these hacks in the future, since duplicate keys are explicitly disallowed.
First off, sorry for the confusion caused by the mislaid locale string :O Totally missed it. And thank you to everyone who jumped in ;)

As agreed with Anthony, I have just prepared a new PR to v2.0 including the suggested changes and removing the inclusion of any new locale strings. I will ask for a new approval in a sec.
Flags: needinfo?(gtorodelvalle)
Attached file 22297.html — 
NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Different appearance of the lock screen when a incoming call reaches the phone and the lock screen is enabled.
[User impact] if declined: Bad user experience. Please see attachment 8458056 [details]
[Testing completed]: Heavily tested on the device. Regarding the "roaming" internationalization using the solution suggested by Doug, I will attach a new screenshot after asking for the approval.
[Risk to taking this patch] (and alternatives if risky): It is a big patch but it has been heavily tested.
[String changes made]: None.
Attachment #8458051 - Attachment is obsolete: true
Attachment #8464581 - Flags: approval-gaia-v2.0?
Roaming internationalization using the solution suggested by Doug and included in the new patch ;)
[Blocking Requested - why for this release]: See comment 70.
blocking-b2g: backlog → 2.0?
As an additional note, mentioning that none of the issues reported in https://tbpl.mozilla.org/?rev=4df436c29ba1f36554b82555a806b959a2920148&tree=Gaia-Try have anything to do with the new proposed patch.
Comment on attachment 8464057 [details] [diff] [review]
L10n hack for 2.0

Although not commented until now, working perfectly, Doug ;) Thank you very much!
Attachment #8464057 - Flags: feedback?(gtorodelvalle) → feedback+
Comments from triage this morning. There are a few issues at play here:

This is a huge patch. It is very late. The patch has gotten checked in and backed out a lot, which does not bode well for this so late in the game.

Yes, it's an ugly experience, but I think we have to let it go given the nature of this patch and the simple fact of what day it is. 

What's disappointing is that this was removed from the 2.0 feature-b2g backlog and should not have been. That was a call for Wilfred to make and that's not what happened here. Only the Product Manager (in collaboration with his/her team) can remove items from the backlog. That's what I wish we'd caught sooner.

Marking this for feature-b2g 2.1 and that should NOT change.
blocking-b2g: 2.0? → ---
feature-b2g: --- → 2.1
(In reply to Stephany Wilkes from comment #75)
> Comments from triage this morning. There are a few issues at play here:
> 
> This is a huge patch. It is very late. The patch has gotten checked in and
> backed out a lot, which does not bode well for this so late in the game.
> 
> Yes, it's an ugly experience, but I think we have to let it go given the
> nature of this patch and the simple fact of what day it is. 
>
> Marking this for feature-b2g 2.1 and that should NOT change.

I don't agree with this decision or the justification for it. I would not call being backed out twice "a lot", considering they were on different branches, and the second time was basically for an administrative issue. As Anthony pointed out in an email, the dialer team has no other blockers and can easily tackle any regressions this causes, if any.

(In reply to Stephany Wilkes from comment #75)
> What's disappointing is that this was removed from the 2.0 feature-b2g
> backlog and should not have been. That was a call for Wilfred to make and
> that's not what happened here. Only the Product Manager (in collaboration
> with his/her team) can remove items from the backlog. That's what I wish
> we'd caught sooner.

I'm also not sure why it matters who was the specific person to change the bug status. Since this isn't communicated anywhere, or is at the very least obscure information, it seems like a poor justification to me. Also, the announcement that 2.0 will won't be taking any more non-blocking bugs came completely out of no where. The only source of information on this that I'm aware of is [1], and it doesn't include the date of this announcement. Had we known about this, we would have responded in a different way.

Here's what I think we learned from this:

* Work should be broken up a lot more than this was. This would have been easy to deal with if it was done over many bugs and we could roll them out gradually. It also would have been easier to justify landing the last one if we were falling behind, since it wouldn't have been as big.

* Relman should do a better job of communicating release/branch statuses to us. We are finding ourselves consistently frustrated with the seeming randomness of decisions and announcements, and there's no good canonical source of information anywhere for us.

* On a similar note, the product manager being the only one allowed to change a bug's feature-b2g status is news to me. Information like this should be communicated somewhere so that we know about it.

[1] https://wiki.mozilla.org/Release_Management/B2G_Landing#Versions_and_Scheduling
status-b2g-v2.0: affected → wontfix
Keywords: late-l10n
I'm setting needinfo for relman because there are action item suggestions in comment 76. I've talked with Lawrence about my second point already and I understand work is being done there.
Flags: needinfo?(release-mgmt)
[Blocking Requested - why for this release]: I'd like another look at this because, like Doug said, we have no blockers and the bandwidth to fix any potential regression.
blocking-b2g: --- → 2.0?
feature-b2g: 2.1 → ---
(In reply to Doug Sherk (:drs) from comment #76)
> I don't agree with this decision or the justification for it. I would not
> call being backed out twice "a lot", considering they were on different
> branches, and the second time was basically for an administrative issue. As
> Anthony pointed out in an email, the dialer team has no other blockers and
> can easily tackle any regressions this causes, if any.

I understand your frustration. Unfortunately, we have very limited time left to stabilize 2.0 and need to reduce churn on the branch. We really don't have any leeway for tackling regressions at this point.

> I'm also not sure why it matters who was the specific person to change the
> bug status. Since this isn't communicated anywhere, or is at the very least
> obscure information, it seems like a poor justification to me. 

In speaking with Stephany, this comment was more about the bug inadvertently dropping off of her list. Has the flag not changed she likely would have pushed on this more.

> Also, the
> announcement that 2.0 will won't be taking any more non-blocking bugs came
> completely out of no where. The only source of information on this that I'm
> aware of is [1], and it doesn't include the date of this announcement. Had
> we known about this, we would have responded in a different way.

If you didn't know about this it's on my team for not communicating the schedule well enough. In general, irregardless of blocking status, once we reach the FC milestone our focus needs to shift from polish to stabilization and shutdown of the release.

Note that the recent change in approval process was about forcing decision making to triage.

> Here's what I think we learned from this:
> 
> * Work should be broken up a lot more than this was. This would have been
> easy to deal with if it was done over many bugs and we could roll them out
> gradually. It also would have been easier to justify landing the last one if
> we were falling behind, since it wouldn't have been as big.

+1

> * Relman should do a better job of communicating release/branch statuses to
> us. We are finding ourselves consistently frustrated with the seeming
> randomness of decisions and announcements, and there's no good canonical
> source of information anywhere for us.

Agreed. Still working on how to communicate this information so that everyone is clear on the current state.

(In reply to Anthony Ricaud (:rik) from comment #78)
> [Blocking Requested - why for this release]: I'd like another look at this
> because, like Doug said, we have no blockers and the bandwidth to fix any
> potential regression.

I understand your desire to fix this however we can live with this in 2.0 and we really don't have time to deal with potential regressions. 2.0 is at the point where our focus needs to be on stability as opposed to polish.
blocking-b2g: 2.0? → ---
(In reply to Lawrence Mandel [:lmandel] from comment #79)
> Agreed. Still working on how to communicate this information so that
> everyone is clear on the current state.

Ok, thanks. Please don't hesitate to contact me if you'd like feedback on how you're going to publish this information.
feature-b2g: --- → 2.1
Flags: needinfo?(release-mgmt)
Comment on attachment 8464581 [details]
22297.html

Clearing the approval here as this was discussed offline and considered risky to uplift at this point.
Attachment #8464581 - Flags: approval-gaia-v2.0?
Blocks: 1050162
Blocks: 1055680
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: