Gaia/SMS/Scrum/2.1S7/Planning

Sprint is from 15oct -> 28th oct
Velocity: [p=6] => with Oleg in PTO, and I'll be away thursday/friday (but I'll still look at review requests from you), and 1 day less for the sprint, that's why I decreased it so much. What do you think? Ok for me

small sprint :)

from current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=1021608 [p=1]
Bug 1021608 - [Messages] Report panel visual refresh

• (Julien) not much left, let's do p=1?

  (Steve) sure (I think it should be ended in last sprint... sorry :/)

  (Julien) it's ok, should be finished today :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1074732 [split a separate bug for the "selectall case", p=2 for the first bug]
Bug 1074732 - [Messages] Create a mixin to handle the "select" UI model

• (Julien) do you have a better idea of what's needed here? Do we need to split the bug a little more or is it ok ? Maybe at least distinguish the various tasks?

  (Steve) I think creating a select model is a clear and unique goal, but maybe need more point for a completed patch.

  (Julien) p=1 was only for last sprint, we'll need to estimate again here of course :) But I don't really know what's needed. Maybe you have some patch to show already? Just so that I can grasp the complexity?

  (Steve) It's still ongoing and unable to run right now... but maybe we can split it into another bug that focus on selectall solution to minimize the scope for this one.

  (Julien) I don't need to make it run, just see the changes :)

  (Julien) so what would be the scope for this one? A minimal mixin with the structure, but then we need more bugs to use it for real? That would work for me.

  (Steve) Probably, and I'll clean up/commit the patch later

  (Julien) in that case, I think we can do p=2 or maybe 3 because we'll have discussions?

  (Steve) p=2 is ok for me if we split into small issue

  (Julien) should we take the new "selectall" bug in this sprint too, or should we keep it for next sprint?

  (Steve) I'm just thinking that as well, maybe not in this sprint first but we can still have it if we have free time

  (Julien) yes ok; it's difficult to estimate the new bug without this one done anyway.. I'll let you split the bug then?

  (Steve) Sure

https://bugzilla.mozilla.org/show_bug.cgi?id=1071514 [split the bug in 2 bugs, p=2 for the first bug]
Bug 1071514 - [Woodduck][Messages] The picture will flicker once when you take one picture as attachment

• (Julien) What's left: decide if we keep the smaller patch for v2.0/v2.1; finish unit tests; handle review comments. Finish the bigger patch for v2.2 (maybe in a separate bug?), I think Jenny wants to give new guidelines?

  (Steve) I think we could finish smaller one first since it's save and got UX positive feedback. I'll push her to leave comment for the master solution(because she got some different thought) I think we need different points for each patch?

  (Julien) ok, I'll split in a separate bug then. I think the master patch is not actionable yet though. so maybe just take the small patch in this sprint?

  (Julien) I also started https://bugzilla.mozilla.org/show_bug.cgi?id=1082073, maybe this one is actionable, but I think I'd rather do it after the other one.

  (Steve) But image resizing with promise is not possible uplift to 2.0m

  (Julien) no no it's only for master :)

  (Steve) Ya it's definitively ok if you prefer to refine the resizing part first.

  (Steve) Just curious, why not just commit your 2.0m patch in Bug 1068490 ?

  (Julien) you mean, rather than bug 1071514? Because when we do patches it should be in public bugs so that it's easier for anyone to come and hae a look (including in 6 months, if we have new peers or contributors that need to do a git blame, etc...)

  (Steve) ok, so you would prefer having both patch in same bug, or create another public bug?

  (Julien) I'll create a separate public bug to make things clearer. We can land the v2.0/v2.1 specific patch in master too and build from it in the other bug. Works for you?

  (Steve) Fine for me, so how about the estimation?

  (Julien) If we agree keeping the small patch, then I think it should not be more than p=2 (unit tests + review). I can't find a way to have a small patch and do the same logic than the bigger patch... and I'm quite afraid of landing a big patch in this area :/ So I'd be ok with losing some memory here. Hopefully we won't have blockers about OOM issue when attaching big images :/ we'll know where too look if this happens ;) Good thing is that when we attach lots of images together in one go, we can't crop them, so the blob will be disk-based and take less memory.

  (Steve) Ya.. we should be careful about these image issues. And p=2 is reasonable

Blocker 2.0m

https://bugzilla.mozilla.org/show_bug.cgi?id=1074069
Bug 1074069 - [Messages] If we get an error when the user tries to send, check if PIN is required

• should we take it?
• It seems not confirmed yet... And is it possible to introduce new string in 2.0M?

  (julien) and it's not a blocker anymore, so let's skip?

  (Steve) ok

https://bugzilla.mozilla.org/show_bug.cgi?id=1069135
Bug 1069135 - [Rose][Woodduck][Case Fail][[Comms]MMS]The "ogg" file will not show play button and save button in MMS

• (Julien) let the device team handle it?

  (Steve) Agree, it's not a difficult one(if we don't need to parse the media)

https://bugzilla.mozilla.org/show_bug.cgi?id=996755
Bug 996755 - [B2G][MMS] Unsupported data formats are not displayed corrected when received by MMS

• It might related to bug 1069135, but we could also make 'application/ogg' as an exception and treat it as video.

  (Julien) this is what bug 1069135 does, right?

  (Julien) ah sorry, there is the SMIL issue you talked about that we can try to land.

  (Steve) Yes, it's about the attachment missing in the SMIL layout, but it's still possible that the ogg is missing in the SMIL as well, not sure.

  (Julien) I've read the bug again; maybe we can ask for the db since they can't try the patch?

  (Julien) I mean, ask it once again :)

  (Steve) ok, I'll ask it *again*

  (Julien) should we take this bug in the sprint, or should we continue handling it in background? What do you think?

  (Steve) Only 1 point left right now, maybe we could do it in background, but not sure if we get any following tasks could satisfy 1 point

  (Julien) except the blob url revocation (and even this could take longer) I agree. So maybe let's take this one, and hopefully next sprint we'll have more time to go on with more long-term tasks.

  (Steve) So p=1 for this one?

  (Julien) if the goal is to land your SMIL patch, yep. If it's not fixing the issue, then maybe we'll need p=2. But I think we have ~2 points left anyway (for the report panel refresh, it's a small point :) )

  (Steve) you're right

  (Julien) I can also take it if you're busy with the mixin bug (in the end of the sprint, we'll see).

  (Steve) I'm fine with it (If you prefer to wait for DB to confirm the solution again)

  (Julien) so let's estimate; I think it does not really matter whether we do p=1 or p=2, so let's choose one. p=1 ?

(Steve) ok

Additional discussion

(Julien) Planning finished then?

(Julien) I'm putting this in bugs and then we land the report refresh patch ;)

(Steve) Thanks, or you have some noticeable tasks that eager to land this sprint?

(Julien) Nothing _really_ urgent. It's nice if we can land the mixin so that we can move forward with more perf work and lazy display the threads in the future :)

(Steve) Agree, will provide patch today or later

(Julien) Also I have a meeting with Wilfred today about v2.2 features so maybe next sprint we'll have a clearer direction for v2.2. I'll keep you in touch :)

(Steve) That remind me that maybe we should arrange a meeting with Jenny

(Julien) She told me she was not ready yet but maybe we can ask again. Have you looked to the draft specs she sent last week?

(Steve) You mean the spec about the recipient and mms label?

(Julien) Yep

(Steve) Ya I just talk with her today, except the dragging gesture, I could accept her idea(especially removing the single line/ multiline mode, which I think it's not really necessary...)

(Julien) Maybe; it's more Fang's advice here :)

(Steve) And for the label, I agree Jenny that putting the label in same place looks better, but your reason is also persuasive because we(devs) don't want to modify this complicate css/html logic again

(Julien) My main issue with this is that I don't like the superposition of the label and the thread. The proposed spec is simpler too so maybe that's easy to do, but I don't think it's good for the user... so that's my main issue :/ Hopefully Fang and Jenny will find a good solution.

(Steve) Before seeing the actually result of their proposal, it's hard to say if it's good or bad visually.

(Julien) Well, I can tell that writing some text on top of other text, it's bad. Especially if the text is the latest message I sent and so my new message will be related.

(Steve) Maybe having a different background color or splitter could help? But it's visual call there

(Julien) I was thinking that we may show it when the user focus the input, and hide it if the user tap the thread and unfocus the input. But even this, I don't like it so much. Maybe a MMS marker on the send button would work better for me. I'll suggest this :)

(Steve) I thought you suggested in the mail?

(Julien) I did not suggest this yet ;) it just ocurred to me while I discuss with you now.

(Steve) Oh you suggested to keeps the double height composer

(Julien) I did not suggest much things for this, I did not have very good ideas actually :/ But I like this one :)