View source for Gaia/SMS/Scrum/FxOS-S4/Planning

Sprint is from July 28th -> August 10th (called FxOS-S4) (2 weeks)

Velocity: [p=7]

PTO ?
* Julien: July 29th is hacking day, July 30th PTO
* Steve: Aug 10th for recovery day
* Oleg: July 29th is hack day, I was thinking about one more PTO this sprint.

=> I roughly counted p=7 (10 days * 3 devs - 5 PTO) / 2 points * 0.6 (velocity)

(Reduced velocity from 0.7 to 0.6.)

==from current sprint==

https://bugzilla.mozilla.org/show_bug.cgi?id=1162030 [p=2]<br>
Bug 1162030 - [Messages][NG] Figure out how navigation works
:(Oleg) I still feel like it more than p1 even that it's in review, maybe p2 or more?
:(Julien) I think at least p2 yes. But I think now p2 is enough, including your reviews and my fixes. (and I reduced velocity as well to account for our bad estimation :p)
:(Oleg) Okay p2 then :)
:(Steve) p=2

https://bugzilla.mozilla.org/show_bug.cgi?id=1169576 [p=3]<br>
Bug 1169576 -  [Messages][NG] Implement Conversation service: method for retrieving of all threads
:(Julien) do we have a clearer idea of dependencies ? Are they resolved ?
:(Oleg) That depends on what you see as dependencies? I'd say it can be landed once reviewed, follow-ups should take care about gradual integration it into application.. and performance as well sounds like a good candidate for follow-ups. What do you think?
:(Steve) will we land this in master even it'll cause regression for sure? 
:(Oleg) But in this patch it's not used anywhere yet, second commit is just for you if you want to test, but I'll get rid of it in final PR or can do it now if it's confusing :)
:(Julien) do you think it would be possible to have a flag in Settings ? I don't mind small perf regressions but I mind big perf regressions :)
:(Oleg) We can have a flag, but this discussion is more for the bug that will be integrating service into app :) In this patch I don't want to modify views at all, but in next one yes if we can (I mean if we manage to improve perf numbers), it would be great to have UI for setting btw.
:(Julien) ok :) yes this plan is good for me. About UI for setting: it means we need a mozSettings flag, and it means... more time at startup likely :p I was more thinking a static flag that we can turn on/off easily but still requires flashing. - ah I see, I was thinking that you meant something in run-time.
:(Steve) Will this flag be applied to all the service, or it's just for performance sensitive service like conversation service?
:(Oleg) main problem with turn-on easily, IMO, is that we should modify manifest to have split views as entry point. I don't really care in turning on services on non-split version :)
:(Oleg) Steve: I was thinking about parts that really affects performance only.. But it depends on what we want to have for 2.5 release
:(Julien) about turning on services for non-split versions: I still one of my initial goal is important: to avoid duplicating code as much as possible.
:(Oleg) Yeah, I mean when we create new-method-a and want to use it instead of old-method-a, we have two options - if performance regression is acceptable (like in MessagingService I'd say) we just start using new-method-a (no need in settings for this case), otherwise - we'll have two versions of method anyway (one for master and one for us until it's ready to go to master).
:(Julien) do you think it's possible to use services without using workers, so that we don't have perf regressions for master ? I know it's more work initially, but I think it's less work over time when we'll have to fix bugs in all parts and forget some etc...
:(Oleg) I think it's doable, but need some time to figure out how exactly - with services we have chance to use some sort of DI where we can replace some parts more easily, but still not trivial - but yeah we can a lot :)
:(Steve) How about discuss this during workweek (for more details)?
:(Oleg) Sounds good for me.
:(Julien) yes we can discuss this during workweek; anyway this bug is not about applying it yet, I think ? I wish we could but up to you.
:(Oleg) Yep
:(Steve) I think the runnable patch for browser is good enough
:(Julien) I don't think it's good enough, what I'm against is duplicated code.
:(Oleg) Sorry, I'm lost - what duplication you're exactly referring in this bug?
:(Steve) Yeah, I'm not sure where is the duplicated part either
:(Julien) With this bug we have a second way to get the threads, right ? It's basically the same code we have in MessageManager for master (albeit with more code to do the service).
:(Oleg) Well, I see, but it's still in-progress-work and we can't use it, once we make it ready then we'll have to decide. That's why I don't see it as dupe for now, but okay it's just details and we all don't want to have duplicated code - so I think we're on the same page with the same goal :)
:(Julien) yes; I know I'm insisting a lot on this because it's just too easy to have 2 sets of files working independently, and I think we'll be bit later if we do that.
:(Oleg) Yeah, I'm totally with you on that, I'm just looking for the best moment/way to remove this duplication so that it won't be too late :) - I'd like a parallel with the "branch" - conversation service "getThreads" now in the "separate branch", once we decide to "merge" (turn on in master) - we should do anything to avoid duplication.
:(Steve) I though the duplication will be existed for a period of time before the methods of service is totally ready, but I'm fine if you prefer to depreciate the old methods case by base.
:(Julien) we can even imagine master's MessageManager as a frontend to service for the methods that are replaced?
:(Oleg) Maybe, let's discuss when we gather together :) 
:(Julien) OK. How much points ? ;)
:(Oleg) I'd say p2 - I need one more feedback, tests and fix feedback/review comments.
:(Steve) Considering the review efforts and you might need to rewrite for test for getThreads method, maybe p=3?
:(Julien) I hesitate between p=2 and p=3 because unit tests are not done yet and the patch is big.
:(Oleg) Okay, voting says p3 - even better for me :)
:(Julien) but that means only 1 point left
:(Oleg) mmm, bad, maybe still p=2, to have more points for Steve's tasks :) We have "blocker" points as well
:(Steve) Depends on which one you prefer :) (Apply messaging service/settings service)
:(Julien) let's do 2 points more, I'm decreasing velocity a little less (0.6 instead of 0.5, was 0.7 before)
:(Julien) note that this is for the bugs we want to absolutely finish this sprint; we can still start working on other bugs then. For example this sprint I'll focus on Navigation patch + doing reviews for your patches, but I'll start working on the system message stuff in background. I think this way we can at least finish the bugs we say we'll finish.
:(Oleg) Okay, let's try
:(Julien) so 2 points left

https://bugzilla.mozilla.org/show_bug.cgi?id=1179628<br>
Bug 1179628 - [Messages][NG] Lay out Settings service structure
:(Julien) is it 2 points for this bug ? or Bug 1180592 ?
:(Steve) Bug 1180592 might be simpler, but I thought you would prefer bug 1184865 first?
:(Steve) I think we should finish mozMobileConnections shim then settings service since settings service is also depends on mozMobileConnections shim.
:(Julien) I think initially bug 1179628 was only about doing the structure of the service but I don't really mind if we do the dependencies first and do all the service then at once :)
:(Julien) so up to you; for 2 points left, which bug do you think we should finish ? Maybe bug 1184865 as you suggest, because it's still some new approach and so it will be good to see how it works (compared to this bug and bug 1180592 where we know quite well how to do them).
:(Steve) Yeah, let's try out 1184865 first and we can ask Wilson more question in workweek

https://bugzilla.mozilla.org/show_bug.cgi?id=1180592<br>
Bug 1180592 - [Messages][NG] mozMobileConnections shim Implementation


https://bugzilla.mozilla.org/show_bug.cgi?id=1184865 [p=2]<br>
Bug 1184865 - [Messages][NG] Replace some methods in MessageManager with messaging service in conversation view
:(Steve) Oleg, do you think this patch should wait for your conversation service patch?
:(Oleg) I'm fine if any of us lands first, the rebase will be quite easy I think
:(Julien) I think this bug depends on bug 1169576 so we should wait. What do you think ?
:(Steve) We must have some conflicts in messaging service(shim iframe should be the same) but not much.
:(Julien) I was confused MessagingService vs ConversationService; we can do this now, you're right.
:(Julien) so remaining p=2 for this one ?
:(Steve) Ok for me
:(Oleg) Same for me

https://bugzilla.mozilla.org/show_bug.cgi?id=818000<br>
Bug 818000 - Figure out how to fix system messages for us (likely implement system messages for service workers)
:(Oleg) !!!! \0/ !!!!

https://bugzilla.mozilla.org/show_bug.cgi?id=1176976<br>
Bug 1176976 - [Messages][Drafts] Remove the draft saving/replacing action menu
:(Oleg) Maybe it doesn't look like very important, but it block my plans on DraftsService :) And it's in review, will likely need several review rounds, but I'd really like to include this in sprint if you don't mind.
:(Julien) if it's blocking (or more likely simplifying :) ) a NG work I'm fine.
:(Oleg) Yeah, it's simpli-blocking :)

==blockers==

https://bugzilla.mozilla.org/show_bug.cgi?id=1160049 [2.5+] [skip]<br>
Bug 1160049 - [Messages] Attach menu should not dismiss when user cancel the replace attachment request
:(Julien) let's skip again, not urgent, not risky

https://bugzilla.mozilla.org/show_bug.cgi?id=1178712 [2.5+] [skip?]<br>
Bug 1178712 - [Message]When we launch  Message from a contact details view for the second time, device does not  enter the compose view, but enters a view where there is only a title  "message".
:(Julien) Same: not urgent, let's skip ?
:(Julien) we should do bug 1032273 but there is also a bug in the System app; I think this specific bug should be handled in the System app.
:(Oleg) I think we can skip, we have several clear workarounds in case we need fix it quickly at some point. Bug 1032273 - seems not very trivial unless Dialer can provide same-as-in-dialer shared lib to validate numbers to have the same experience. And what I don't like with my current SIM (T-Mobile) that I receive sms messages from string-based number - and it looks confsing when I tap on call button and nothing happens at all :) Don't know what is the good UX for this though.
:(Steve) I thought the number field we have is always the actual phone number. So it is string for the T-Mobile SIM?
:(Oleg) I just see "Fehler" (transl. "Error") as message sender. I know I don't have any reason to call back - but if we had shared-validation-lib - we'd hide this call button.
:(Julien) let's discuss about this again when it will be more urgent to do this :p
:(Oleg) Sure :)

==nominations==

https://bugzilla.mozilla.org/show_bug.cgi?id=1149345 [2.5?] [skip]<br>
Bug 1149345 - [Messages][Threads] Images can be attached to incoming messages, and corrupt the thread it was originally meant for.
:(Julien) This is not actionable, we need activity.cancel().


==features==

https://bugzilla.mozilla.org/show_bug.cgi?id=1161521<br>
Bug 1161521 - Do not spam the user with error messages

https://bugzilla.mozilla.org/show_bug.cgi?id=1180470<br>
Bug 1180470 - [Messages] Propose a setting to disable sending the read report