Threshold for tapping defined on build time

RESOLVED FIXED

Status

RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: crdlc, Assigned: crdlc)

Tracking

unspecified
x86
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g18+ fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
It's a parameter that will heavily depend on the hardware, we should add it as a parameter that manufacturers modify during build time

I mean, we should add this value to the build/applications-data.js file and make it configurable by specific build.
(Assignee)

Updated

6 years ago
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
(Assignee)

Comment 1

6 years ago
Created attachment 708996 [details]
Patch v1
Attachment #708996 - Flags: review?(francisco.jordano)
Comment on attachment 708996 [details]
Patch v1

Tried on the device and working well

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Feature needed to perform correctly in the developer phones. Moving this parameter to the build phase will allow us to adjust a better experience for the different hardware we have right now.
User impact if declined: If we don't make this configurable per device we can ship builds which homescreen could be potentially unusable
Testing completed: yes
Risk to taking this patch (and alternatives if risky):not very risky as it's moving a constant to the already working configuration by build time
Attachment #708996 - Flags: review?(francisco.jordano)
Attachment #708996 - Flags: review+
Attachment #708996 - Flags: approval-gaia-v1?
tracking-b2g18: --- → ?
This looks like something we'd want some testing around before uplifting.  Can you land to master and then provide build (or builds) for them to test out - put the 'qawanted, verifyme' keywords in when test builds are ready
(Assignee)

Comment 4

6 years ago
This bug depends on https://bugzilla.mozilla.org/show_bug.cgi?id=829050. It uses some code implemented in 829050 so if it is not uplifted we shouldn't land this one
Depends on: 829050

Comment 5

6 years ago
(In reply to crdlc from comment #4)
> This bug depends on https://bugzilla.mozilla.org/show_bug.cgi?id=829050. It
> uses some code implemented in 829050 so if it is not uplifted we shouldn't
> land this one

Can this be separated from bug 829050? That bug appears to have non-zero risk, and has little benefit to 1.0.0 and 1.0.1 users.
No longer depends on: 829050
(Assignee)

Comment 6

6 years ago
I prefer wait a couple of days for the final decision before separating code. Or maybe, is the decision taken? If finally the other bug won't go in v1, I prefer remove that from master and this one will implement the common code. So we could do the uplift easier. After that, I could implement the other one based on master implementation provided for this.
We're still waiting for product input on bug 829050, leaving this in triage for now.
Flags: needinfo?(ffos-product)
What, exactly, is this threshold adjusting?
If we don't allow it to be adjusted during build time, is there another way for the OEM to adjust it?
Given that bug 829050 is blocking, is it safe to assume that this risk is minimal?
(Assignee)

Comment 11

6 years ago
Here the risk is minimal based on the other bug. It was tested by me and the reviewer
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → affected
tracking-b2g18: ? → +
Comment on attachment 708996 [details]
Patch v1

Approving based on low risk assessment.
Attachment #708996 - Flags: approval-gaia-v1? → approval-gaia-v1+
This bug is generating a lot of complaints.  Can we get it uplifted?  (Downstreams are working around it with their own patches, which isn't what anyone wants.)
Flags: needinfo?(jhford)
v1-train: 0d1ef3c5b9a0a94bf0461c9ce70855f63cb760e7
v1.0.1: 2e646c0fe299e4b7054dac5e0e22058a4d4b23e4
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed
Flags: needinfo?(jhford)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #14)
> This bug is generating a lot of complaints.  Can we get it uplifted? 
> (Downstreams are working around it with their own patches, which isn't what
> anyone wants.)

This bug was not showing up in the queries that I was given by release management because the the bug is still ASSIGNED and not RESOLVED/VERFIED->FIXED
(Assignee)

Updated

6 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

6 years ago
This bug is not on v1.0.1 and v1-train if I am not wrong
Flags: needinfo?(jhford)
Yep, I can confirm that those objects aren't on the branches, not sure how that happened.

Unfortunately, there are merge conflicts when trying to apply the diff to v1-train and v1.0.1 now.
status-b2g18: fixed → affected
status-b2g18-v1.0.1: fixed → affected
Flags: needinfo?(jhford)
(Assignee)

Comment 19

6 years ago
Please paste here the commands and I could help you resolving conflicts
 git checkout v1-train
 git cherry-pick -x -m1 3c070039c0818e8dcab45fb90e8743c52e7d8f3d
 <RESOLVE MERGE CONFLICTS>
 git commit
 git checkout v1.0.1
 git cherry-pick -x $(git log -n1 v1-train)
 <RESOLVE MERGE CONFLICTS> # If they exist
 git commit
marking branch fixes per comment 21,22
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed
Flags: needinfo?(ffos-product)
You need to log in before you can comment on or make changes to this bug.