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

Status: RESOLVED FIXED

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

Description

[Maria Angeles Oteo (:oteo)]

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.

Comment 1

[Stephany Wilkes]

Please let me know if you expect this to land before the end of Sprint 3 this Friday. FC is June 9. Thanks!

Comment 2

[Germán Toro del Valle (:gtorodelvalle)]

Hi Stephany! Yes, I am currently working on this once the patch for bug 950884 landed yesterday in master ;) I'll keep you posted.

Comment 3

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: 20054.html

BTW, since I am sitting next to Vicky here in Taipei, she gave me the ui-review+ on the fly... ;-)

Comment 4

[Anthony Ricaud (:rik)]

Attachment: 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.

Comment 5

[Stephany Wilkes]

Flagging Victoria and Carrie to see if they can clarify.

Comment 6

[Carrie Wang [New account: [e-mail]]]

Attachment: [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!

Comment 7

[Victoria Gerchinhoren [:vicky]]

(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!

Comment 8

[Germán Toro del Valle (:gtorodelvalle)]

Need-infoing Carrie regarding comment 7 ;)

Comment 9

[Maria Angeles Oteo (:oteo)]

(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).

Comment 10

[Maria Angeles Oteo (:oteo)]

(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.

Comment 11

[Germán Toro del Valle (:gtorodelvalle)]

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.

Comment 12

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: lockscreen-multi_sim.png

Comment 13

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: callscreen-lockscreen-multi_sim.png

Comment 14

[Germán Toro del Valle (:gtorodelvalle)]

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 :)

Comment 15

[Carrie Wang [New account: [e-mail]]]

Yes, the incoming call icon is not necessary on lockscreen. Sorry for the false alarm! Thanks!

Comment 16

[Anthony Ricaud (:rik)]

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).

Comment 17

[Pau Masiá [:Pau]]

Attachment: Visual Mockup. DSDS. Lock screen incoming call. Short name

Visual Mockup to show how the SIM indicator should be displayed.

Comment 18

[Pau Masiá [:Pau]]

Attachment: Visual Mockup. DSDS. Lock screen incoming call. Long name

Specs to follow.

Comment 19

[Pau Masiá [:Pau]]

Attachment: Visual Spec. DSDS. Lock screen incoming call

Comment 20

[Germán Toro del Valle (:gtorodelvalle)]

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.

Comment 21

[Germán Toro del Valle (:gtorodelvalle)]

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 22

[Greg Weng [:snowmantw][:gweng][:λ]]

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.

Comment 23

[Etienne Segonzac (:etienne)]

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 :))

Comment 24

[Anthony Ricaud (:rik)]

I couldn't take a look yesterday, I'll do that on Monday.

Comment 25

[Anthony Ricaud (:rik)]

Comment on attachment 8434758 [details]
20054.html

Thanks for the huge work and the effort to move files to JSHint!

Comment 26

[Anthony Ricaud (:rik)]

Both Travis and Gaia-try are not very happy though so please fix this before landing.

Comment 27

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: callscreen-lockscreen-screenshots.pdf

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!

Comment 28

[Germán Toro del Valle (:gtorodelvalle)]

Should be covered in bug 1010104 ;)

Comment 29

[Victoria Gerchinhoren [:vicky]]

Comment on attachment 8447057 [details]
callscreen-lockscreen-screenshots.pdf

OK. The baseline is still not solved, but + for the rest.

Comment 30

[Germán Toro del Valle (:gtorodelvalle)]

Landed in master: https://github.com/mozilla-b2g/gaia/commit/05670c059f2d4772b3557bd7bd5d88507f784b27

Comment 31

[Carsten Book [:Tomcat]]

sorry had to revert this change for failing gaia unit tests like https://tbpl.mozilla.org/php/getParsedLog.php?id=43016816&tree=B2g-Inbound

Comment 32

[Germán Toro del Valle (:gtorodelvalle)]

We have to come up with some kind of solution here because they were passing locally and in Travis... :-(

Comment 33

[Greg Weng [:snowmantw][:gweng][:λ]]

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.

Comment 34

[Germán Toro del Valle (:gtorodelvalle)]

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!

Comment 35

[Doug Sherk (:drs) (inactive)]

Germán, would you like me to take a look at the test results so we can get this landed?

Comment 36

[Germán Toro del Valle (:gtorodelvalle)]

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 :(

Comment 37

[Doug Sherk (:drs) (inactive)]

Looked good to land, so I went ahead with it. Thanks Germán!

https://github.com/mozilla-b2g/gaia/commit/4847968c251ebc03c3f4b5b79e884e5511018db5

Comment 38

[Germán Toro del Valle (:gtorodelvalle)]

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 ;)

Comment 39

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: master_lockscreen.png

Comment 40

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: master_lockscreen_incoming_call.png

Comment 41

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: v2.0_lockscreen.png

Comment 42

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: v2.0_lockscreen_incoming_call.png

You'll notice the difference if you compare this screenshot to attachment 8456009 [details].

Comment 43

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: 21804.html

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

Comment 44

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: v2.0-vs-v2.0_with_patch-incoming-call-when-lock-screen-enabled.png

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.

Comment 45

[Doug Sherk (:drs) (inactive)]

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.

Comment 46

[Germán Toro del Valle (:gtorodelvalle)]

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 ;)

Comment 47

[Germán Toro del Valle (:gtorodelvalle)]

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 ;)

Comment 48

[Ryan VanderMeulen [:RyanVM]]

Looks like the v2.0 pull request needs rebasing.

Comment 49

[Germán Toro del Valle (:gtorodelvalle)]

Just did it, thanks! Waiting for TBPL verdict for merging ;)

Comment 50

[Germán Toro del Valle (: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!

Comment 51

[Ryan VanderMeulen [:RyanVM]]

You can merge it yourself.

Comment 52

[Germán Toro del Valle (:gtorodelvalle)]

Merged in v2.0: https://github.com/mozilla-b2g/gaia/commit/a89900c2a38cf2b61245807c75ffdb76d49e72f6

Thanks Ryan!

Comment 53

[Axel Hecht [:Pike]]

(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?

Comment 54

[Doug Sherk (:drs) (inactive)]

(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 55

[Preeti Raghunath(:Preeti)]

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.

Comment 56

[Ryan VanderMeulen [:RyanVM]]

Reverted at Preeti's request.
v2.0: https://github.com/mozilla-b2g/gaia/commit/90a5a08192586f3e91852053e76fbb8321273f9d

Comment 57

[Anthony Ricaud (:rik)]

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

Comment 58

[Doug Sherk (:drs) (inactive)]

(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.

Comment 59

[Axel Hecht [:Pike]]

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.

Comment 60

[Anthony Ricaud (:rik)]

Germán: Could you provide a patch against 2.0 that adds system.en-US.properties to the callscreen manifest? Thanks!

Comment 61

[Francesco Lodolo [:flod]]

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)?

Comment 62

[Staś Małolepszy :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.

Comment 63

[Doug Sherk (:drs) (inactive)]

(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.

Comment 64

[Francesco Lodolo [:flod]]

(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.

Comment 65

[Doug Sherk (:drs) (inactive)]

Attachment: L10n hack for 2.0

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.

Comment 66

[Staś Małolepszy :stas]

(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.

Comment 67

[Francesco Lodolo [:flod]]

(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.

Comment 68

[Doug Sherk (:drs) (inactive)]

(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.

Comment 69

[Germán Toro del Valle (:gtorodelvalle)]

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.

Comment 70

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: 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.

Comment 71

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: bug-1018283-incoming-call-when-lockscreen.png

Roaming internationalization using the solution suggested by Doug and included in the new patch ;)

Comment 72

[Anthony Ricaud (:rik)]

[Blocking Requested - why for this release]: See comment 70.

Comment 73

[Germán Toro del Valle (:gtorodelvalle)]

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 74

[Germán Toro del Valle (:gtorodelvalle)]

Comment on attachment 8464057 [details] [diff] [review]
L10n hack for 2.0

Although not commented until now, working perfectly, Doug ;) Thank you very much!

Comment 75

[Stephany Wilkes]

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.

Comment 76

[Doug Sherk (:drs) (inactive)]

(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

Comment 77

[Doug Sherk (:drs) (inactive)]

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.

Comment 78

[Anthony Ricaud (:rik)]

[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.

Comment 79

[Lawrence Mandel [:lmandel] (use needinfo)]

(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.

Comment 80

[Doug Sherk (:drs) (inactive)]

(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.

Comment 81

[bhavana bajaj [:bajaj]]

Comment on attachment 8464581 [details]
22297.html

Clearing the approval here as this was discussed offline and considered risky to uplift at this point.