Closed Bug 1206641 Opened 9 years ago Closed 9 years ago

Merge BaseModule to TV System App

Categories

(Firefox OS Graveyard :: Gaia::TV::System, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.5+)

RESOLVED FIXED
FxOS-S8 (02Oct)
blocking-b2g 2.5+

People

(Reporter: jj.evelyn, Assigned: jj.evelyn)

References

Details

(Whiteboard: [ft:conndevices][partner-blocker][partner-cherry-picked<2015/11/4>])

Attachments

(1 file)

46 bytes, text/x-github-pull-request
rexboy
: review+
etienne
: feedback+
Details | Review
Since we are going to backport some components from phone's system app (2.5) to TV system (2.1), with BaseModule back-ported first, our life will be easier. However, we won't migrate all components in smart-system in BaseModule shape, we just want back-ported new features using BaseModule.
System owners, it seems we only need bug 1072757. Could you suggest any follow-up or related bugs we need to pick as well?
Flags: needinfo?(timdream)
Flags: needinfo?(etienne)
Flags: needinfo?(alegnadise+moz)
I would say bug 1072757 turn out to be the fundamentals of bug 1094759 (More than just SettingsCore) and I am not aware of other bugs.

Is the scope of this bug is only about allowing new TV code to inherit BaseModule? If so I guess bug 1094759 or some kind of smart copy-paste of the current System app should do it.

I would not recommend TV system try to re-implement bug 1094759 in it's own folder -- that would be a departure from trying to merge the two app instead of a way to get there -- unless we want to experiment first.
Flags: needinfo?(timdream)
(In reply to Evelyn Hung [:evelyn] from comment #1)
> System owners, it seems we only need bug 1072757. Could you suggest any
> follow-up or related bugs we need to pick as well?

If the goal is to be able to migrate modules with little to no change I think you'll also need
* bug 1062819 for the STATES support
* bug 1080905 (simple rename, but it should help preventing conflicts)
* part of bug 1094759 for the |loadWhenIdle| support (you might want to take just the base_module.js/base_module_test.js part of the patch...)
* bug 1156596 which I think is for the TV :)
* bug 1166214
Racing a bit but looks like we agree :)
Flags: needinfo?(etienne)
It's not possible to redo the whole work of bug 1094759 nor back porting it to TV. 

What we want is when an existing phone's module uses |BaseModule.create| to create itself, the code could be run on TV as well without too much modification (e.g. bug 1206621). Therefore, my guess was just bug 1072757 needed. Less modification at this moment helps two System merge task in the future.
(In reply to Etienne Segonzac (:etienne) from comment #3)
> (In reply to Evelyn Hung [:evelyn] from comment #1)
> > System owners, it seems we only need bug 1072757. Could you suggest any
> > follow-up or related bugs we need to pick as well?
> 
> If the goal is to be able to migrate modules with little to no change

Yep, you know me. :)

> I think you'll also need
> * bug 1062819 for the STATES support
> * bug 1080905 (simple rename, but it should help preventing conflicts)
> * part of bug 1094759 for the |loadWhenIdle| support (you might want to take
> just the base_module.js/base_module_test.js part of the patch...)
> * bug 1156596 which I think is for the TV :)
> * bug 1166214

Great! Thank you. I will take a look of these bugs.
blocking-b2g: --- → 2.5+
Priority: -- → P1
In this patch, I try to just pick a common and minimum set of functions provided by BaseModule, therefore only backported Bug 1072757 and Bug 1062819. Now we have SERVICES, STATES, IMPORTS, SUB_MODULES, EVENTS, and SETTINGS of BaseModule. I tested SERVICES, STATES and SUB_MODULES by copying FeatureDetector to TV, and it works well. Not sure if there is a simple way to test EVENTS and SETTINGS, I will keep investigating.

I didn't take bug 1094759 for the |loadWhenIdle| support because it seems not so critical now, and we could always backport this part if we find a case using it. Bug 1156596 and bug 1166214 are made for the preparation of system app merge, so we won't need it now.

I'd like to get your feedback first. Thank you. :)
Attachment #8664129 - Flags: feedback?(timdream)
Attachment #8664129 - Flags: feedback?(etienne)
Target Milestone: --- → FxOS-S8 (02Oct)
Assignee: nobody → ehung
Status: NEW → ASSIGNED
Comment on attachment 8664129 [details] [review]
backport BaseModule to TV

It is preferable if we could backport the tests too to prove/maintain the claims with machines :)
Attachment #8664129 - Flags: feedback?(timdream) → feedback+
Blocks: 1207521
Comment on attachment 8664129 [details] [review]
backport BaseModule to TV

(In reply to Tim Guan-tin Chien [:timdream] (slow response; please ni? to queue) from comment #8)
> Comment on attachment 8664129 [details] [review]
> backport BaseModule to TV
> 
> It is preferable if we could backport the tests too to prove/maintain the
> claims with machines :)

Yeah we definitely want to backport base_module_test.js too :)

But it might me easier to just snapshot the current version of base_module.js and base_module_test.js. They are pretty stable and I don't think there's much value in keeping references to older system bugs since we're only partially backporting them (and not cherry picking commits).

The changes to core.js and service.js should still be good.
Attachment #8664129 - Flags: feedback?(etienne)
Comment on attachment 8664129 [details] [review]
backport BaseModule to TV

Updated according to comment 9 that I just copied the current base_module.js and its test to smart-system, and it works! Let me know if I missed anything else. Thanks!

@yifan, since your work might depend on this module when you backporting Data Sync logic to TV, please checkout this patch as well, and let me know if it doesn't fit your case. Thanks!
Attachment #8664129 - Flags: review?(rexboy)
Attachment #8664129 - Flags: review?(etienne)
Attachment #8664129 - Flags: feedback?(yliao)
Attachment #8664129 - Flags: feedback+
Comment on attachment 8664129 [details] [review]
backport BaseModule to TV

Looking good, we should probably squash the PR too.
Trick question: are the tv_apps/* unit tests running on try?
Attachment #8664129 - Flags: review?(etienne) → feedback+
Yes, according to Bug 1162887 - (gu-tv) Support tv_apps unit test on Gu job . For example we could find smart-home and smart-system unit tests in GU20.
Comment on attachment 8664129 [details] [review]
backport BaseModule to TV

Ran GijTV locally and all passes.

Notice some difference in the core.js. While trying to backport sync to smart-system with this patch, I found that the _start method in core.js is quite different, one major difference is that the method in system/js/core.js returns a Promise. Not sure if this will break any code after we add lazily loaded modules in smart-system/js/core.js. Probably need some check to make core.js work as apps/system does.
Attachment #8664129 - Flags: feedback?(yliao)
Comment on attachment 8664129 [details] [review]
backport BaseModule to TV

I'm just not sure which service.js you used, but looks good to me.
Attachment #8664129 - Flags: review?(rexboy) → review+
There is a service.js in smart-system which was added by John, probably a snapshot when we forked system app. Thing I did in this patch is adding just necessary code for base module.
Merge into gaia-master
https://github.com/mozilla-b2g/gaia/commit/106f1806a6889fedd6708aebd3a602cf71ca8ee0
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [ft:conndevices][partner-blocker] → [ft:conndevices][partner-blocker][partner-cherry-pick]
Blocks: 1210697
Flags: needinfo?(alegnadise+moz)
Whiteboard: [ft:conndevices][partner-blocker][partner-cherry-pick] → [ft:conndevices][partner-blocker][partner-cherry-picked<2015/11/4>]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: