Milestone planning - April 15th -> May 26th

velocity =~ 30

Stories for next generation architecture

In this section, we define the stories we want to handle in the v3 architecture.

Find questions to answer

(Julien) can we already answer them or do we need the v3 toolkit ready?

(Oleg) Haven't found the right section for my question, but how do we plan to organize development, will we create our dedicated feature branch ?

(Julien) I think we'll need a feature branch; we can try hard to land as much as possible on master, and only land very disruptive things on the branch (ex: the document split: we can land on the branch the various HTML files, but the JS could be made generic enough to land on master?). We'll need to take care to merge master to the branch quite often. Or do you think that with a proper flag we could stay on master branch only?

(Oleg) Honestly I believe it will be quite difficult to work directly on master, or at least I don't have good idea in mind how we can do this :)

(Steve) Agreed with Oleg... I don't think it's easy to merge back to master, Why not starting a message2 developing app or something?

(Julien) Oleg says it's difficult to work on master directly; I don't like having a separate app because we'll lose all history. A separate branch on the same app is good enough IMO?

(Oleg) Do you guys have rights to create branch on the upstream mozilla-b2g-gaia?

(Julien) I think I can; I'll ask Kevin first, but having a common branch for all team could be useful.

(Oleg) yep, especially if System needs some work as well, that it doesn't want to merge to upstream/master yet, so we (Sms and Music) can rebase our branches on top if it for example. Don't really know, just idea :)

(Julien) I take the action of creating/asking a branch; we'll also need to define who maintains it.

(Julien) otherwise I still think there is some work we can do on master too, but this will be decided on case by case :)

(Steve) Just ask Dominic (Music) and they will work on master directly.

(Julien) do they plan to break master ?

(Steve) They plan to do refactoring first an wait for lib ready. But it's just draft and they'll have discussion today later.

(Julien) I think we can try to do the same for most of our work :) maybe even split the files can be done on master -- there is no problem if we don't really use them.

Other questions to answer? I mean, it can be a real task to answer some questions. For example: "do we need the render cache?". "Where do we put telemetry?" "How do we handle our Navigation steps?" :)

Telemetry

(Oleg) What this thing will include? :)

(Julien) there are parts that are handled by the lib automatically (how much time do we take to slide panels) and other things we can decide ourselves (how many sending errors, etc). We can take some time to decide what we want to measure.

(Oleg) Sounds like we can rely only on telemetry gathered automatically for the "1st" stage. And think of more advanced and sms-specific cases during implementation.

(Julien) a task in next sprints can be to decide this already :) Sprint tasks are not always dev-related :p I think it would be a good deliverable for next "milestone" (in 6 weeks).

(Oleg) Yeah, that's what I mean, just decide what we want to gather and not how to do it at least :)

(Julien) you got it :) For now I just want the questions, and we can answer some of them just by thinking ;)

(Oleg) Okay :) The first thing that comes in mind is how big thread list and threads are :) To know what cases are more frequent - I'm wondering if it's "open" info. Okay then, our task for this sprint is to decide what we want to measure.

(Julien) not necessarily next sprint, next milestone :) (but if we decide it's the most important task, it could be next sprint)

Render cache

(Steve) I don't think we need to consider it for this sprint, but it could be important

(Oleg) Agree, at least during first sprints we can have more thoughts on how difficult to implement this, but I'd really like to, though complexity is scaring

(Julien) I think we'll need to do it at least to determine if we want it :)

(Oleg) The good thing is that render cache can be turned-on/off on per view basis.

(Julien) yep. I'm really frightened about the idea of taking HTML and sticking it inside a innerHTML. But the security team can help.

Navigation with Content Wrapper

(Steve) Navigation should be important firstly, especially we will need to separate the panel now. Will it depend on any gecko changes?

(Oleg) Have you guys looked/tried Wilson's CW draft (I pasted link to "little-browser" into GDoc), so he says it should work, has issues, may be totally redone, but works :D

(Julien) not yet ! I thought our first step is to load the panels individually in Firefox with mocks, and only then play with CW. Do you think another order could be better? Here I especially think about all our flows around drafts; I know we want to eventually kill the dialogs but they're still here and we don't want to navigate until the user answers them.

(Oleg) No, I agree with your order. One more thing is to make it work in desktop browser, it's much easier than using WebIDE, but it's only imo :)

(Julien) I definitely agree with this, but you know that ;)

Define main use cases and UX flows, and see how this works with Service Workers

(Steve) Still not sure about the main UX flow differentiation comparing current master and new architecture, examples?

(Julien) especially related to how we handle system messages

(Oleg) mmm, do you think it will be different from UX POV?

(Steve) I can't think of any difference from UX (about the system message) :/

(Julien) not UX :) ok maybe my sentence was weird. When I say "define", maybe it was more "review" :)

Split the application in separate documents for main panels

• Find and remove dependencies between panels
• create one HTML file per panel, make it possible to load them separately in Firefox
  • define how to pass arguments
• others?

Split current js into front-end and back-end

(Julien) is this more or less the case already? At least we need to review our code. But I'd say it's fairly organized already (eg: contacts.js, threads.js => backend; thread_ui, threadlist_ui, compose, recipients => frontend).

(Oleg) We also need to decide which parts we want to move to workers - e.g. that's is shared between views and can occupy memory, time to bootstrap and it's beneficial to have it in shared worker. I can only think of the code that will work with IndexedDB/MozAPI

(Steve) Yes it should clear in our code base, but may still some time to revist all of them, and the define which part could put to worker for gaining more.

(Julien) yes; and maybe see/decide if some existing files need to be split in 2 files.

IndexedDB-in-Gaia

(Steve) Nice to have but not necessary item for new architecture. Maybe we can only have thread table first(having more ability to access the threads, especially for cold launch)?

(Julien) if we have the thread store, it's easy to have everything :)

(Julien) this is IMO not necessary but really useful -- so that we don't need a costly proxy to the APIs.

(Oleg) In case we decide to move forward with it, can it be split between us or it's more monolithic?

(Julien) I think it's difficult to to be split -- except reviews will need to be done by both of you IMO :)

(Oleg) So your IndexedDB patch based on MozApi, right? If so we need iframe-worker-iframe(with MozApi) workaround or we'll have some dev patch on Gecko that will allow us to use MozApi in worker, I heard smth like this from Francisco, but not sure.

(Julien) We'll always need to access MozAPI anyway; the IDB patch will need a migration path that uses the MozAPI (the migration path is not clear in my head yet -- ideas welcome); when sending messages we'll need to use the MozAPI; when a contact changes we'll use the MozAPi too. So we'll need the workaround anyway. But if we have a IDB, the workaround does not need to be extra-performant. It only needs to work.

(Oleg) Yep, I mean what workaround we should use, the one in gaia (iframe-worker-iframe) or the one in Gecko (that allows to use MozApi in worker, if possible of course)?

(Julien) I don't think it's really decided yet, but I expect it will be one in Gaia. (and anyway, if it's in Gecko, it will be the same mechanism, they also "proxy" it between threads, so the performance issues will still apply).

(Steve) Could we assume the workaround would be implemented in the lib? Or app-wise need that handle it anyway.

(Julien) as I understand it, the lib will have a mechanism to help implementing it, but we'll need to implement using the lib. Which is likely a good thing... we can proxy only what we need, in the way we need.

(Oleg) So it's our(SMS) task to work on it and not to wait for anybody to provide the lib? Because I see we'll need it very soon.

(Julien) I don't expect to work with workers before the libs are (quite) ready.. but maybe I'm wrong?

(Oleg) I believe bridge (threads) is quite ready already, it's basically worked in Paris :) I think we should start using it as soon as possible to pin point problems early.

(Julien) okay then !

Move to separate repository

(Julien) IMO it's too early. Pointer to do it while keeping history (and even maybe keep the real app in Gaia while still having a separate repository): https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt

(Oleg) Ah, here is the right section for my branch-question :) Sorry

(Julien) I added it just 5 minutes ago ;) \0/

Pain points

Lazy loading for a thread (bug 887198)

(Steve) When user select all in edit mode with thread partially traversed, will it select all 'visible' threads or all existing threads?

(Julien) all existing threads (note: this is not working currently if the thread is not fully loaded yet); this is why your patch about decoupling is important for this :)

Notifications for errors (bug 933133)

(Steve) Maybe we'll need UX input first?

(Julien) IIRC Jenny already gave input here but we can check.

Blockers

Refactoring to fix existing bugs

Especially related to recipients.

Prioritization of features

Features are groups of stories.

General Stories

• Story: Which questions do we need to answer ? (are there others) [julien 1][oleg 2][steve 1]

Telemetry

• Story: What do we want to measure ? [julien 13] [oleg 14][steve 14]

Render cache

• Story: What views will be beneficial to store in render cache? (and how difficult is this?)[oleg 7][julien 12][steve 13]

Navigation with Content Wrapper

• Story: Split panels in separate documents [oleg 1] [julien 3][steve 3]
• Story: Find out how Navigation steps work [julien 5][steve 8][oleg 9]
• Story: Review UX flows with the Content Wrapper + Service Worker mechanism / Define the Data Flows [julien 3][oleg 10][steve 5]

Service Worker

• Story: Review existing JS files to determine if they are frontend/backend. If some should belong to both, they need to be split.[oleg 3] [julien 8][steve 4]
• Story: IndexedDB in Gaia [julien 4] [oleg 8][steve 9]
• Story: Proxy mozAPI / Define which ones we use and we need in Worker [oleg 6][julien 9][steve 7]
• Story: Use the Bridge [oleg 5] [julien 6][steve 6]

How we work

• Story: Branching [julien 2] [oleg 4][steve 2]
• Story: Separate repository [julien 15] [oleg 15][steve 16]

Fix Blockers

We'll need to do this anyway; it's more taking a toll on our velocity ;)

Pain Points

• Story: Reporting errors using notifications [julien 7] [oleg 12][steve 11]
• Story: Lazy Loading heavy threads [julien 11] [oleg 11][steve 10]

Refactoring

• Story: Refactoring Recipients [julien 10] [oleg 13][steve 12]

Non-technical features

• Story: Group MMS (note: some people are asking me about this these days) [julien 14] [oleg 16][steve 15]

Estimates

We're estimating the stories in the priotization order defined previously.

Story: Split panels in separate documents

Estimate: [julien 5][oleg 10][steve 10]

Story: Which questions do we need to answer ? (are there others)

Estimate: [julien 1][oleg 1][steve 1]

Story: Branching

Estimate: [steve 1][julien 3][oleg 1]

(Julien: I think we need also to define how we merge between master and the branch)

Story: Review existing JS files to determine if they are frontend/backend. If some should belong to both, they need to be split

Estimate: [julien 2][oleg 2][steve 2]

Story: Use the Bridge

Estimate: [julien 3][oleg 3][steve 5]

Story: Review UX flows with the Content Wrapper + Service Worker mechanism / Define the Data Flows

Estimate: [julien 5][oleg 4][steve 3]

Story: IndexedDB in Gaia

Estimate: [julien 10][oleg 8][steve 15]

(Oleg: really have no idea, how much is done, and how much is still needed)

(Julien: take as granted that not much has been done :) )

Story: Find out how Navigation steps work

Estimate: [julien 3][oleg 2][steve 3]

Story: Proxy mozAPI / Define which ones we use and we need in Worker

Estimate: [oleg 5][steve 5]

Story: Reporting errors using notifications

Estimate: [oleg 2][steve 2]

Story: What views will be beneficial to store in render cache? (and how difficult is this?)

Estimate:

(Julien: I think we exceeded 30 so we can stop estimating; we now have an idea of what we can do in 6 weeks)

(I'll send this to our owners, maybe they'll want some features before some of the other things... we'll see)

(second note: given we started things below, maybe we can also at least finish the WIP patches we have.. ? today ? :p)

(Oleg: I think we should finish what we've already started if it's not very time consuming, at least I started not very difficult things)

(Julien: yeah I agree; I'll include some of the things in the planning, we can review tomorrow anyway -- if not finished today :) )

Story: Refactoring Recipients

Estimate:

Story: Lazy Loading heavy threads

Estimate:

Story: What do we want to measure ?

Estimate:

Story: Group MMS (note: some people are asking me about this these days)

Estimate:

Story: Separate repository

Estimate:

Result for next Milestone

• Story: Split panels in separate documents [Estimate ~8.3]
• Story: Which questions do we need to answer ? (are there others) [Estimate 1]
• Story: Branching [Estimate ~1.6]
• Story: Review existing JS files to determine if they are frontend/backend. If some should belong to both, they need to be split [Estimate 2]
• Story: Use the Bridge [Estimate ~3,6]
• Story: Review UX flows with the Content Wrapper + Service Worker mechanism / Define the Data Flows [Estimate ~4]
• Story: IndexedDB in Gaia [Estimate ~11]
• Story: Find out how Navigation steps work [Estimate ~2.6]