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
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
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
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)
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
- (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 :)