903232 - [Settings] Remove CDMA network modes from the default list after finishing CDMA development

Status: RESOLVED FIXED

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

Description

[Arthur Chen [:arthurcc][inactive after 6/30]]

In bug 891742 and bug 881862 we display all network modes by default for CDMA development and testing. We should remove the CDMA options after finishing CDMA development.

Comment 1

[Beatriz Rodríguez [:brg]]

This is a certification blocker for launching v1.2. Nomintating accordingly.

Comment 2

[Ivan Tsay (:ITsay)]

The network mode should depend on the phone network capability.

Comment 3

[Arthur Chen [:arthurcc][inactive after 6/30]]

Removing CDMA modes from the default is trivial. Plan to do so in the end of the development of this release as currently QA may still depend on this for testing.

Comment 4

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: link to https://github.com/mozilla-b2g/gaia/pull/13059

Yuren, coul you help review the change? Thanks.

Comment 5

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Comment on attachment 821521 [details]
link to https://github.com/mozilla-b2g/gaia/pull/13059

looks good for me, partner can customize this values using customization mechanism if needed.

Comment 6

[Arthur Chen [:arthurcc][inactive after 6/30]]

master: https://github.com/mozilla-b2g/gaia/commit/844582094cb8aa08d4d842185222bb7ee347fc04

Comment 7

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 844582094cb8aa08d4d842185222bb7ee347fc04 to:
v1.2: e017aaa274079000af93833087b3e13ba417085b

Comment 8

[Anshul]

There are two issues with the change.

1. This change is causing a regression on 1.2 where the network mode setting shows as empty.
2. This change is also uplifted to 1.3 when 1.3 is still an active development target for CDMA. Please revert this change on 1.3 branch as it is hindering our CDMA development on that branch.

Comment 9

[Anshul]

On further testing the issue #1 in my comment #8 is not an issue. However we would still like to keep the cdma network modes on the gaia master. Yuren, is there any way to do that, perhaps using gaia customization as per your comment #5? Please provide some information.

Comment 10

[Arthur Chen [:arthurcc][inactive after 6/30]]

Not sure when is a good timing to remove CDMA options. Maybe we can show all of the options only on debugging builds. For production builds, we use customization files.

Comment 11

[Anshul]

Can we keep all the options on master and let the OEMs customize?

Comment 12

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

yes, follow below steps to customize network:

1. mkdir distribution_dir and put network.json into this folder.
2. |GAIA_DISTRIBUTION_DIR=<PATH_OF_distribution_dir> make| in GAIA_DIR

this is a customizied network.json for you reference:
> {
> 	"types": ["wcdma/gsm", "gsm", "wcdma", "wcdma/gsm-auto", "cdma/evdo",
>               "cdma", "evdo", "wcdma/gsm/cdma/evdo"]
> }

Comment 13

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Anshul from comment #8)
> There are two issues with the change.
> 
> 1. This change is causing a regression on 1.2 where the network mode setting
> shows as empty.
> 2. This change is also uplifted to 1.3 when 1.3 is still an active
> development target for CDMA. Please revert this change on 1.3 branch as it
> is hindering our CDMA development on that branch.

Isn't v1.3 what's on master?  Would you like this backed out on master?  Should this also be backed out on v1.2?

Comment 14

[Anshul]

Yes we would prefer this change to be reverted on master.

Comment 15

[Arthur Chen [:arthurcc][inactive after 6/30]]

Anshul, does the way suggested in comment 12 work for you? If we keep showing all options by default on master, we need to remove CDMA options every time we branch.

Comment 16

[Anshul]

Arthur, I understand your concern. However these options are something that OEMs need to manage for every release rather than we managing for them. Starting from 1.3 all releases would support all these network modes I suggest we enable all the modes for development/testing and let the OEMs customize. Does it make sense?

Comment 17

[Arthur Chen [:arthurcc][inactive after 6/30]]

I agree that the modes should be customized by OEMs. My another concern would be currently we did not re-design the UI for showing all CDMA and GSM options at the same time in settings app, thus it looks weird. ni? Kevin for inputs.

Comment 18

[Kai-Chih Hu [:khu]]

In this case, should we move it to 1.3 or 1.4? Suggest to have it in 1.4.

Comment 19

[Anshul]

Kevin, I would like to see the change in 1.3 as 1.3 is where we support CDMA and is still an active CDMA development target for us.

Comment 20

[Kai-Chih Hu [:khu]]

Thanks, Anshul. 
I would like to inform Sandip about this. Sandip, what do you think? We are in sprint 4 of v1.3 now. Should we put it in v1.3?

Comment 21

[Kai-Chih Hu [:khu]]

So, it looks like that Anshul is suggesting to have CDMA included in the default build. 

What we have now are:
1. Roaming preference is for CDMA only. 
2. Operator selection is for GSM only. 
2. Network type does not displays CDMA for GSM build. 

If we mix them together(GSM and CDMA) in the default build, it might be a little bit weird. Sandip, what's your take here?

Comment 22

[Sandip Kamat]

(In reply to Kevin Hu [:khu] from comment #20)
> Thanks, Anshul. 
> I would like to inform Sandip about this. Sandip, what do you think? We are
> in sprint 4 of v1.3 now. Should we put it in v1.3?

I am okay in keeping both options as chipset makers are still actively working on dev builds for cdma on 1.3. We can let OEM do the actual settings here based on what they have in their modem capabilities.

Comment 23

[Arthur Chen [:arthurcc][inactive after 6/30]]

Per comment 22, revert the change on master: 409bd1962a294faab1585cbb50903a2a62a80364

Comment 24

[Beatriz Rodríguez [:brg]]

Comment on attachment 821521 [details]
link to https://github.com/mozilla-b2g/gaia/pull/13059

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

[Approval Request Comment]
Now that 1.3 version is about to be commercial. We need to land this fix to pass certification. It is a blocker.
[Bug caused by] (feature/regressing bug #): This fix was removed from master (when master was 1.3) but now that master is not 1.3 but a commercial proposal, we need this fix.
[User impact] if declined: User will be able to see some options in the settings menu that do not work for only WCDMA devices
[Testing completed]: It was tested and working in 1.2.
[Risk to taking this patch] (and alternatives if risky): Sorry, I do not know.
[String changes made]: None, the patch is to remove current options in settings menu.

Comment 25

[Anshul]

(In reply to Beatriz Rodríguez [:brg] from comment #24)
> Comment on attachment 821521 [details]
> link to https://github.com/mozilla-b2g/gaia/pull/13059
> 
> NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to
> better understand the B2G approval process and landings.
> 
> [Approval Request Comment]
> Now that 1.3 version is about to be commercial. We need to land this fix to
> pass certification. It is a blocker.
> [Bug caused by] (feature/regressing bug #): This fix was removed from master
> (when master was 1.3) but now that master is not 1.3 but a commercial
> proposal, we need this fix.
> [User impact] if declined: User will be able to see some options in the
> settings menu that do not work for only WCDMA devices
> [Testing completed]: It was tested and working in 1.2.
> [Risk to taking this patch] (and alternatives if risky): Sorry, I do not
> know.
> [String changes made]: None, the patch is to remove current options in
> settings menu.
Beatriz, can this work not done by OEMs?

Comment 26

[bhavana bajaj [:bajaj]]

(In reply to Beatriz Rodríguez [:brg] from comment #24)
> Comment on attachment 821521 [details]
> link to https://github.com/mozilla-b2g/gaia/pull/13059
> 
> NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to
> better understand the B2G approval process and landings.
> 
> [Approval Request Comment]
> Now that 1.3 version is about to be commercial. We need to land this fix to
> pass certification. It is a blocker.
> [Bug caused by] (feature/regressing bug #): This fix was removed from master
> (when master was 1.3) but now that master is not 1.3 but a commercial
> proposal, we need this fix.
> [User impact] if declined: User will be able to see some options in the
> settings menu that do not work for only WCDMA devices
> [Testing completed]: It was tested and working in 1.2.
> [Risk to taking this patch] (and alternatives if risky): Sorry, I do not
> know.
> [String changes made]: None, the patch is to remove current options in
> settings menu.

We are granting approvals only on blockers(1.3+), hence I am setting the blocking-b2g to 1.3? for triage team to consider this...From the look of the patch it does not feel risk and make a blocking case given its a cert blocker..

I am curious why did we find this out this late and should this be a part of mozilla config or vendor ?

Comment 27

[Preeti Raghunath(:Preeti)]

blocking on this given its a cert blocker.

Comment 28

[Beatriz Rodríguez [:brg]]

I can ask each OEM who will launch devices in TEF countries to make this change manually but please keep in mind that open market consumers in other places will get a device with a setting without meaning... thats why I think this fix should land in all the commercial branches or find a way to avoid this issue.

Comment 29

[Arthur Chen [:arthurcc][inactive after 6/30]]

The patch should not be uplifted to v1.3 as we now rely on gecko for providing information of supported network types after bug 950185 landed. To have gecko report correct values, OEM should write system properties describing the capability of each sim slot. Please refer to this comment[1] for details.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=980831#c0

Comment 30

[Beatriz Rodríguez [:brg]]

Comment on attachment 821521 [details]
link to https://github.com/mozilla-b2g/gaia/pull/13059

Cancel the request after previous explanation.