Gaia/SMS/Scrum/FxOS-S7

From MozillaWiki
< Gaia‎ | SMS‎ | Scrum
Jump to: navigation, search

List of bugs

SMS issues handled by the SMS subteam (blocks the sprint bug 1202956)

Bugzilla link

Full Query
ID Assigned to Summary Blocking b2g Feature-b2g Whiteboard Resolution
818000 Julien Wajsberg [:julienw] system messages are ignored if the handler pathname is not the same as the foreground application pathname --- No cf_feature-b2g [sms-sprint FxOS-S7 p=3][sms-sprint FxOS-S6 p=2][sms-sprint FxOS-S5 p=3] WONTFIX
1180592 Steve Chung [:steveck] [Messages][NG] mozMobileConnections shim Implementation --- No cf_feature-b2g [sms-sprint FxOS-S7 p=1][sms-sprint FxOS-S6 p=2] FIXED
1198266 [Messages] Use ConversationService in the application --- No cf_feature-b2g [sms-sprint FxOS-S8 p=1][sms-sprint FxOS-S7 p=3][sms-sprint FxOS-S6 p=2] WONTFIX
1201016 [Messages][NG] Migrate the current Message manager event handling to NGA --- No cf_feature-b2g [sms-sprint FxOS-S8 p=1][sms-sprint FxOS-S7 p=1] WONTFIX

4 Total; 4 Open (100%); 0 Resolved (0%); 0 Verified (0%);


Remaining points and burndown chart

google chart api url for Sprint FxOS-S7

Burndown chart
Remaining points
Start 8
Day 2 8
Day 3 7
Day 4 7
Day 5 7
Day 6 7
Day 7 7
Day 8 7
Day 9 7
Day 10 7
End


SMS issues handled by the SMS subteam outside of the sprint (contains whiteboard "sms-sprint-FxOS-S7")

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


All SMS issues tracked for this sprint (target milestone)

Bugzilla link

Full Query
ID Assigned to Summary Blocking b2g Feature b2g Resolution
1184012 Stéphane Roucheray [Messages] Throttle event handlers for the "input" event handlers --- --- FIXED
1202956 SMS sprint FxOS-S7 --- --- INCOMPLETE

2 Total; 2 Open (100%); 0 Resolved (0%); 0 Verified (0%);


Sprint planning

Minutes are on a separate page.

Daily meetings

Day 2: 9th September

Steve

  • bug 1179628 - [Messages][NG] Lay out Settings service structure
    • Start mozMobileConnections.
  • bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation
    • In review.
  • bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
    • Have some discussion with Oleg about the possible layout for client.
  • Reply some bugs that related to message app.

Today:

  • Start some layout for message event handling.
  • Clean up the review

Oleg

  • bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
    • No progress (in review).
  • bug 1198266 - [Messages] Use ConversationService in the application
    • Trying updated bridge, couldn't make window-iframe communication work, looking into (in progress).
    • More profilings, had to build b2g by myself to get more info about setupShadowRoots, but results are controversial - data is different between runs, trying to understand what is going on.

Other:

  • Started to look into "bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation.";
  • Finished reading my bugmail.

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Julien

  • In PTO

Day 3: 10th September

Steve

  • bug 1179628 - [Messages][NG] Lay out Settings service structure
    • Start mozMobileConnections.
  • bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation
    • r+ and waiting for green signal.
  • bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
    • Working on the message clone first, maybe I will give a general clone for message since there is sms/mms for DOMMessage. In this way I might need to create a shim utils for clone method. Not sure if other shim will need clone(seems not except the DOMError).
(Oleg) Yeah, presumably only mozMobileMessageShim will need clone, btw do we have any updates on DOMError handling (in bridge I mean)?
(Steve) No from bridge as far as I know :/ But I don't want to push Wilson too much on this since there's lot of task waiting for him.
(Oleg) Heh, yeah, not that critical for us right now. He was also asking me about any news on gaia-fast-list, not sure if he reached out to you cause I don't know anything about it :)
(Steve) Oh I didn't catch up with the latest fast-list yet because the library changes frequently :p
(Oleg) Ah, okay, we can wait for more stabilized version first then.
(Steve) Yeah that's what I thought, I already tried out 2 different version of the fast-list, but maybe it's time to involve again after few weeks.
(Oleg) Okay, got it, thanks for the update! Maybe we can plan it for the next sprint.
  • Clean up the review queue.

Today:

  • Start some layout for message event handling.

Oleg

  • bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
    • No progress (in review).
  • bug 1198266 - [Messages] Use ConversationService in the application
    • Created reduced test case and filed github issue for the problem I was facing: https://github.com/gaia-components/bridge/issues/83.
    • My WIP with auto switch to SharedWorker/alwaysLowered based services is moving forward (in progress).
      (Steve) Just discussed this with other folks yesterday, we thought that the service should be flexible for user to choose/switch between window/worker thread, not just service -> worker concept. So user can designate different context to init and switch the service context between both context seamlessly. Anyway we thought is good change if we can try out different combination.
      (Oleg) Yeah, it's kind of Manager that existed in the early bridge days, that can transparently change contexts/threads :)
    • Tried new bridge with sync window-to-window messaging - works quite well from the first look, at least faster than MessageChannel.
    • Was stuck with Gecko profiler that missed gaia-header related information, asked help from Ting-Yu, got reply - need to try again. Will file a bug to somehow lazy load gaia-headers in the meantime.

Other:

  • Reviewed "bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation.";
  • Attended late NGA meeting on behalf of Julien.

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Julien

  • In PTO

Day 4: 11th September

Steve

  • There's a addon hackathon here, I didn't join the entire event but will still be a passer-by and voting for the result.
  • bug 1179628 - [Messages][NG] Lay out Settings service structure
    • Start mozMobileConnections.
  • bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation
    • Landed.
      (Julien) I was so happy when I saw this bugmail :)
  • bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
    • Have a quick patch about the message clong and message relay between different context. Still fighting with the init race condition and thinking about if it's possible that message missing while initializing the bridge and connection.

Today:

  • Start some layout for message event handling.
  • Feedback for conversation service.

Julien

  • Just read/handled my bugmail and some of the other mails yesterday

Today: I want to:

  • finish handling some more complicated bugmails and mails (eg: low storage stuff)
  • handle review/feedback/NI queue
  • work on the system messages issue

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).

Oleg

  • bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
    • No progress (in review).
  • bug 1198266 - [Messages] Use ConversationService in the application
    • Created WIP-for-your-feedback with ConversationService in window context with ability to upgrade to SharedWorker context (awaiting feedback).
    • Tried to leverage new sync bridge behaviour (window->window, window->iframe via dispatchEvent), but we have a race here - if client is created before service starts listening there is no connection is established, it doesn't happen with BC - will talk to Wilson if it's expected, if yes - we'll need to initialize window clients (that uses iframe service) once service is initialized. We don't have such cases yet, but I have one in my WIP patch.
      (Julien) Note that having a sync behavior kind of defeats the purpose of services; but if we use it only for the initial loading I think it's ok.
      (Oleg) Yep, I'd like to use for startup only and then upgrade to better "channel".
    • Retested alwaysLowered window and noticed significant improvement - we spend ~200-300 ms less to create that window - so filed a bug where we can seriously consider switching to it.
      (Julien) good, this is less a headache for us :) Do we know if it's automatically closing when the app's last window is closing?
      (Oleg) IIRC, yes, but we need more concrete/definite answer from Francisco or System app guys :)
      (Julien) OK; we'll also need to check how this behaves regarding the task manager.
    • Ting-Yu's advice with -e parameter helped to get more detailed profile.

Other:

  • Filed bug for possible better handling of gaia-header;

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 5: 14th September

Steve

  • bug 1179628 - [Messages][NG] Lay out Settings service structure
    • mozMobileConnections shim landed. So the next step is splitting the settings into further: Not sure if we want to move everything into settings service, especially the static value like mms size that only needed for conversation view. Just don't think some static value should be in settings service, but not sure where would be more appropriate(view client seems not "shareable" but it doesn't need to share across all views) :/
      (Julien) I'm not sure I follow the "view client not shareable" part of your comment here...
      (Steve) For example the mms size, we can have a fixed value for conversation for now, but what if we split the new message view in the future. Adding duplicate fixed mms size in new message view client?
      (Julien) mmsSize needs to come from settings -- some partners change it.
      (Steve) Okey I missed it, I think we can cache the value in views if we want.
      (Julien) yeah, the value doesn't change while the app is running. Also not sure this should move to Services for now, but arguable.
  • bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
    • Patch created for feedback. Also thinking about the duplicate the event fired from different instances. Is that silly if we bind the event name with app instance directly...? Because I think it's still a penalty if we receive all the events and filter in client side.
      (Oleg) I think we can at least try this option as well, in my WIP I'm becoming a bit worried about growing number of cases where we need this appInstanceId, but don't have better idea right now....
      (Steve) It might be a little off the topic: despite current implementation we made, do you think it's a good pattern that developer need to take care about the app instance id for all the service client communication?
      (Oleg) No, I don't like it, it's quite easy to miss and brings unnecessary complexity, I've tried to solve it in my first WIP with bridge_client mixin, but it's not what I really like... But we need to figure out better solution so that service and client developers care about this much less.

Today:

  • Address the feedback in message event handling patch and fix the duplicate event issue.
  • Feedback for conversation service.

Julien

I feel like I only did bug creation (from what I've seen during my PTO) and bugzilla bug management...

  • I still produced a small patch in bug 1183133 with Contacts hack, to eliminate the white flash (have a green flash instead), and show David how this was looking. I'll try to move this somewhat forward with an opacity transition like Contacts, but really in background.
  • spent some time reading the mails about the low storage feature, had a meeting about it too. We should have an updated spec soon. Ah, just noticed Katie sent it last night: https://mozilla.box.com/s/bfrwwxdaz1o646h8tmmnlq61lv92sy3f

Today: I want to:

  • handle review/feedback/NI queue
  • work on the system messages issue

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).

Oleg

Will take unexpected day off on Tuesday, so worked on the past weekend instead, and will have planned PTO on Wednesday.

  • bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
    • No progress (in review).
  • bug 1198266 - [Messages] Use ConversationService in the application
    • Wasn't able to have numbers comparable with master with nested iframe, but only if all services are in the same window on startup, so worked on another WIP to have services in window on startup and then upgrade ConversationService + MessaginService to SharedWorker and MozMobileMessageShim from window to alwaysLowered window. It's likely not the best way to handle this, but at least it was easy to keep all these upgrades in single-and-easily-switchable ServiceManager (awaiting feedback).
    • Unfortunately I was wrong about perf improvement in alwaysLowered window - it just was silently failing due to the lack of right permission, so numbers are still bad :/ Updated perf numbers on the bug and github benchmarking app.
    • Found bug in alwaysLowered window that prevents me from testing WIP on device "bug 1204299 - [System] alwaysLowered window steals focus from the main application window".
    • Just some observation: alwaysLowered window is bound to the particular app instance (they are placed in the same parent node from the System app POV), so once instance is closed alwaysLowered window is closed as well. So even that e.g. activity instance has access to alwaysLowered window created by main instance (via window.open with window name and empty URL) we can't really use it as it will disappear once main instance is closed. So that's why I still use appInstanceId trick.
      (Julien) maybe a silly question: if we use the command "window.open('...', 'name')", it will create the window if not existing, and otherwise return it, right? And all mozAPI shims are stateless. So do we really need the appinstanceID ?
      (Oleg) Yes, it will re-create window if you set URL, if not it will create window with empty URL. What did you mean by '...' - is it empty string or actual URL? The main problem is that this window can die, while SharedWorker service connected to it - will not, that will break connection.
      (Julien) you can always use the actual URL.
      (Oleg) But this will re-create window once again or I missing something? At least this is what I've seen. The only way to get the same reference is to omit URL and provide "window name" only. And this is what mentioned in mdn for window.open
      (Julien) Mmm yeah that's right. (note this should not recreate window but reload the URL in the same window -- but for us it's the same issue)
      (Oleg) If I remember correctly System app re-created it - since the id of the window had changed. Ah about Desktop - yeah maybe - haven't tried :)
      (Julien) yeah but on Desktop that's not happening, I think... so maybe there is an issue in the System app here. (but for us we don't want to reload the page anyway). - right.
      (Julien) and is it possible to first request the window, know that it does not exist, and open another one? Or maybe that's what you're doing already ?
      (Oleg) If I call window.open(, 'window_name') and window hasn't been created - we'll have new window created with empty URL I think - not null - but need to double check. So I use sessionStorage currently to understand if this window has been created..... Don't have better idea right now. And activity instance has it's own "session" so they are separated.
      (Julien) OK; it doesn't feel we have the right tools...
      (Oleg) Yep, and alwaysLowered is just temp workaround due to absence of SW, openWindow and etc.... So we're doing gaia workarounds for Gecko/System workarounds :)
    • Also confirmed that both SharedWorker and alwaysLowered window stays alive (and communication between them! :)) when we navigate from one document to another in a split view mode (and when refresh page with f5 as well), checked only Fx Desktop (needs some fix in our desktop mock shims though), but not on a device due the issue above.

Other:

  • Left feedback for "bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA".

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 6: 15h September

Steve

  • Have a family event tomorrow(9/16)
  • bug 1179628 - [Messages][NG] Lay out Settings service structure
    • Not sure if I should start this part for 2.5 :p
      (Julien) we need to continue moving things forward; we'll have the time in October to do otherwise. Worse case is: we put all the services in the same window. But it's still good to have the services IMO :)
  • bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
    • Replay some question and take some time on dealing the event in inbox view
  • Have a glance with the low storage 2.5 spec and discussed with Morpheus.
  • Still looking the conversation service(service initializer)

Today:

  • Address the feedback in message event handling patch and fix the duplicate event issue.
  • Feedback for conversation service.

Julien

Spent most of my time doing reviews:

  • bug 1136147: remove the call to cleanFields before sending a message; this bug is very costly because the contributor is not autonomous at all...
  • bug 1201016: move message manager events to NGA
  • other not-related-to-sms reviews
  • looked at bug 1037620 (add notice for messages late arrival) where the contributor left a good proposal.
    • looked at latest proposal for low storage
  • got the infomation about what we need to do for 2.5 and later
    • (Steve) So any specific reason that we stop the view separation work for 2.5? Is it because of low device storage and may occupy the resource or?
      (Julien) main reason is lack of prerendering and service workers, we can't do something that look fast without these tools...
      (Steve) Ok, I ping you on irc

Today: I want to:

  • handle review/feedback/NI queue
  • work on the low storage issue

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).

Oleg

  • PTO

Day 7: 16th September

Julien

Again a slow day, I got busy with external things...

  • clarified the possible solutions in bug 1190613 (for System FE team)
  • looked at the code for the mozContacts API for bug 1114525, to have an idea of the needed work
  • started some background work to avoid updating the thread node for draft changes.
  • started reviewing Oleg's patch in bug 1176976 again

Today: I want to:

  • handle review/feedback/NI queue
  • start work on the low storage condition

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).

Steve

PTO

Oleg

PTO

Day 8: 17th September

Steve

  • bug 1179628 - [Messages][NG] Lay out Settings service structure
    • Start to plan the possible layout of the general settings service
  • bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
    • Implemented message event handling in inbox. Since it'll need bridge lib and related scripts in cold launch patch, I'm using raptor to measure how much penalty it may bring.
  • Leave some question about the conversation service/service initializer

Today:

  • Address the feedback in message event handling patch and fix the duplicate event issue.
  • Layout for settings service

Julien

Again a slow day, I got a lot busy with external things :/

  • spent a lot of time on Oleg's patch in bug 1176976 but got interrupted a lot, so it's still not finished. I'll resume today for sure.
(Oleg) Sorry for the huge patch :/

Today: I want to:

  • handle review/feedback/NI queue
  • start work on the low storage condition

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).

Oleg

  • bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
    • Got some feedback from Julien, will read and reply if needed (in review).
  • bug 1198266 - [Messages] Use ConversationService in the application
    • Took a closer look to the performance with the WIP, we're regressing ~200ms in visuallyLoaded, I think we can shave a bit here, but don't think too much because of all this bridge machinery involved, and obviously regress on fullLoaded, but I'm not too worried about the latter. The latter mostly regressed due to slow initialization of alwaysLowered window - started to profile on the dedicated test-case app - at least to involve relevant people and move the solution for this problem forward.
      (Julien) we don't really need the alwaysLowered window now that we don't to split views anymore; I mean, for activities it's still nice to have, but not as much needed.
      (Oleg) mmm, my main point is that we can't start use any services on startup that depends on mozShims inside iframe - it's just too slow. So we'll likely put them to window context. Yeah, we either can leave them there or upgrade later to alwaysLowered - but agree now it's not a priority :( The main (only?) benefit of this window is to save some time when we navigate between views in "split" mode, that's not going to happen for v2.5.

Today:

  • Handle bug mail;
  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs. Will work mostly on this today as I have some feedback already :)

Day 9: 18th September

Steve

  • bug 1179628 - [Messages][NG] Lay out Settings service structure
    • Left some thought on bugzilla, will give a WIP for early feedback.
  • bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
    • Seems some regression for cold launch and memory is hard to avoid, not sure we should take this for inbox in 2.5.
      (Julien) I think we need to move forward; again, worst case is we take the services in the same window, but best case is Gecko engineers can decrease the memory usage of workers (if that's the only memory issue of course).

Today:

  • Read the replay about the conversation service.
  • WIP for settings client layout
  • Review rishav's patch

Julien

  • still spent some time on Oleg's patch in bug 1176976 but still not finished
  • answered rishav's requests in bug 1183074 (explaining current state for group MMS) and bug 1180470 (describing how the "send read report" toggle could work)
  • replied to Steve's idea about the Settings shim too.

Today: I want to:

  • handle review/feedback/NI queue
  • start work on the low storage condition

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).

Oleg

  • bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
    • Fixed ongoing review comments and affected unit , waiting for the rest before pushing updates (in review).
  • bug 1198266 - [Messages] Use ConversationService in the application
    • Replied to the questions at GitHub and tried to explain the idea in general (in progress, awaiting feedback).

Other:

  • Handled bugmail/other ;

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Day 10: 21st September

Steve

  • bug 1179628 - [Messages][NG] Lay out Settings service structure
    • Create a WIP for that implement settings client mmsSize & maxConcat methods and use it for compose init. Will replace the mmsSize in activity handler.
  • bug 1201016 - [Messages][NG] Migrate the current Message manager event handling to NGA.
    • Gave some more testing about the new message event handling and will work on the unit test.
  • Clean up the ni and review.

Today:

  • Read the replay about the conversation service.
  • Complete the prototype of settings client layout.

Julien

Slow day because I spent a lot of time working on a slidedeck for last week-end's event. Note: tomorrow afternoon I'll be in the train and finish early, wednesday I'm in PTO.

  • still spent some time on Oleg's patch in bug 1176976 but still not finished; finished the code part, will work on the testing part today.
  • did some bug triaging for new bugs

Today: I want to:

  • continue handling review/feedback/NI queue
  • start work on the low storage condition

If all this moves forward well, I could:

  • continue the prototype caching the thread list to a single db (including contacts/drafts/etc).

Oleg

Will take PTO for the second half of the day tomorrow.

  • bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
    • Replied to new review comments, started to fix what is needed (in review).
  • bug 1198266 - [Messages] Use ConversationService in the application
    • No progress (awaiting feedback).

Other:

  • Investigated "bug 1205988 - [Messages]Enter Messaging Settings view, then device receives a MMS, but it can't back to Messages view when user taps the notification";
  • Investigated "bug 1203886 - The back button in sms conversation view does not always work"

Today:

  • Will handle review/feedback/need-info requests;
  • Will work on review comments and assigned bugs.

Demos

Retrospective

No demo this time

Previous sprints' actions

From 2.1S3:

  • Look into VM with gaia dev environment
    Nothing more done in this sprint

From 2.1S5:

  • in planning for sprint N, we pick some items we want to do in sprint N+1 to ask early questions to UX and Designers (esp refresh bugs, but also bugs with UX changes)
  • we'll add screenshots of panels in Wiki, with the various cases for these panels, to help analyzing change impacts and not forgetting things
    Oleg started this: https://wiki.mozilla.org/Gaia/SMS/Current_App_State

From 2.2S4:

  • undercommit in the sprints.
  • use bugs and github's PR for spec definition and changes

From 2.2S14:

  • move more discussions to #gaia
  • figure out 2.5 features for SMS

From FxOS-S3:

  • split patches as much as we can when we develop it, and split bugs as much as we can when planning them.

From FxOS-S7:

  • stand-up at 11:30am CET / 5:30pm Taipei

What was good in the last sprint

  • I could review Oleg's patch about draft handling ;) This is good because I really want this in the next version, and I feel the next round of review will be easier :p
  • We have new contributor(?)
    • yeah, Stéphane :) he's actually having interviews to enter our team these days \0/ He is a positive guy, I'm happy with this decision :)
    • Wow, good news :)
    • on the same note, we have 2 good candidates now; we have another one to start soon. (Note: I'll remove this from the etherpad before putting on wiki :p)
  • I was finally able to wrap up something with new services and window context that can potentially be landed in master some day :)
  • Rishav is back.

What was bad in the last sprint

  • it feels like we did the smallest amount of work ever :/
    • same feeling; but when I looked at last planning, I can see a lot of points were for investigation, so I think it was as expected ?
    • Right + PTOs, so yeah, just expressed my feeling :)
  • I don't really like how we planned low storage
    • You mean we had to allocate points for it during last planning?
    • No, by "we" I mean "the managing team that decided to do it"; the spec and discussions lasted so much time... you don't see everything ;)
    • Ah, good to know :)

Any questions

  • So it's the last NGA-only sprint, right? October is for blockers? (just confirming that nothing has changed)
    • Actually in this sprint we'll need to focus on low storage first.
    • Yep, got it.
    • Then about blockers, we have a lot, so maybe it could be good to take one or 2 (political reasons :p).
    • Should we also consider blocker outside message?
    • not yet, I think. Only when our blockers are at 0. But if you have time I'm sure the dialer/contacts team would be glad ;)

Actions for next sprint

  • the time for the stand-up does not work very well for me after all; I'd like to try later in the day (like 1:45pm CET, don't know if this works for Steve)
    • I usually in Gym between 12 - 13.30 +- 20 min (Monday, Wednesday, Friday).
    • 2pm then ? I'd like to try coming to the office earlier, and the standup at 9 is preventing me from preparing usually :)
    • 2pm is ok for me, when do you usually come to the office? :)
    • I see it's really late for Taipei. Maybe 11:30am ? or earlier ? I usually arrive around 11 but I'd like to arrive earlier :)
    • anything before 12 is good for me :)
    • 11:30 works for me, so start from tomorrow?
    • tomorrow I'm not here :p but otherwise yep
    • When Julien is not there, I'm fine with any time works best for you, Steve :)
Retrieved from "https://wiki.mozilla.org/index.php?title=Gaia/SMS/Scrum/FxOS-S7&oldid=1096566"