Gaia/SMS/Scrum/2.0S6/Planning

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

Minutes

Velocity: 10 (ok?) Let's try with 10

Bugs from current sprint

  • https://bugzilla.mozilla.org/show_bug.cgi?id=990020
    (Oleg) this one will be carried over to the next sprint
    (Julien) should we move the refactoring to a separate bug?
    (Oleg) I'd rather move it to a separate one, and not include refactoring into the sprint, it's more like background work
    (Julien) ok, exactly what I think too. So we can just land the first commit and not include this in the sprint then.
    (Oleg) yeah, I'll divide it, so is it r+ for 1st commit?
    (Julien) yep :)
    (Oleg) nice! :)
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1033260
    • the patch is ready for review, will need a v1.3t patch too (only resolve conflicts, I think)
    (Julien) p=1
    (Oleg) p=1 if we don't need to do much custom work for 1.3t
    (Julien) Steve also already did a v1.3t patch actually, so it should not be difficult to adjust it
    (Oleg) Ah, then definitely p=1
  • any other started bug I'd miss ?
    (Oleg) do you think this one won't be 2.0? https://bugzilla.mozilla.org/show_bug.cgi?id=1034100 ? I'm not sure whether it will be noticeable by target market users (non-english keyboards and etc.)
    (Julien) the fact is that it's happening on older versions too. But only on HD devices (and we didn't have much HD devices before). So I don't know. Until we know, let's ignore it ;)
    (Oleg) ok :)

blockers

  • 2.0+ bug 1022575: https://bugzilla.mozilla.org/show_bug.cgi?id=1022575
    • needs a gecko bug to send sms-deleted event: bug 1023695
    • risky to take it for this sprint
    • needs work in Threads.js: find a thread from the message id (or find the message from the message id)
    • we can possibly start the work in threads.js in a separate bug? or in bug 1024835, see below
    what about this one? I'd advise either taking bug 1024835 or do a separate bug for the background work. What do you think?
    (Oleg) I think it's not really actionable, I'd rather not include it into sprint. About background work... I see you think we'll have to do something similar for the bug 1024835, or we still need another bug for the background work?
    (Julien) I'd do a separate bug so that we can make it 2.0+ without needing to uplift the whole bug 1024835 (which could not be 2.0+). Danger is to do the wrong or too much background work ;) So maybe we should just take bug 1024835...
    (Oleg) 1024835 looks much more actionable, I'd rather take it to the sprint (even that I can repro it :) ) But this work will be definitely needed, so there is a low risk that we'll waste time
    (Julien) ok, let's take 1024835 instead then :)

nominations

  • 2.0? https://bugzilla.mozilla.org/show_bug.cgi?id=1024835
    • with some carrier, we receive the MMS notification with a generic sender, so it ends up in the wrong thread
    • needs work in Threads.js: find a message from the message id
    • basically lots of things are common to bug 1022575
    (Julien) some background work, not easy to test on a device, I'd do at least p=2
    (Oleg) p=2 sounds reasonable
    (Julien) p=2 it is
  • This bug worries me: https://bugzilla.mozilla.org/show_bug.cgi?id=1029188
    (Oleg) so were you able to repro this?
    (Julien) not yet but I haven't tried with the latest info. I know Natalia had the same issue with the same phone/same version here in Paris too.
    (Julien) not actionable so let's not take it in the sprint; I'll still work on it behind the scene, and if it's made a blocker, we'll work on it anyway.
    (Oleg) agree
  • 2.0? https://bugzilla.mozilla.org/show_bug.cgi?id=1034600
    • The suggestions list looks badly located
    • some of the CSS is shared in different places
    • some markup change
    • if this regressed here because of other work, it's possible that fixing this will regress other places, so we need to test well
    (Oleg) p=2
    (Julien) yeah, at least p=2: markup change, testing... but this can be done in Firefox, so it's easier ;)
    (Oleg) :) Composer/To field is complex beast, we will never have p=1 for something like this :)
    (Julien) should we do p=3 ? or p=2 is already big enough?
    (Oleg) I think p=2 is ok
    (Julien), ok, good for me. 3 left then :)
  • 2.0? https://bugzilla.mozilla.org/show_bug.cgi?id=1034633
    • some padding issue in the subject handling
    • only CSS, adjustments to the visual refresh
    (Julien) I don't really know the code, you should know better :)
    (Oleg) I believe p=1
    (Julien) ok, I think the same

other

haida work

  • https://bugzilla.mozilla.org/show_bug.cgi?id=944249
    • completely move the send button/character counter/message type handling to compose.js
    • could be needed for some MADAI work too
    (Julien) I'd like to take it in the sprint because MADAI needs it. Maybe we can do this + the next bug in the same time, or maybe not, it's not really clear what "other" is.
    (Oleg) next two will have intersecting changes I think
    (Julien) I see more this as a sequence :) first this one, then next one, then separation :) The 2 latest ones are independent though.
    (Oleg) Ok, so since we take this, a lot of work required for this one?
    (Julien) not a lot of code, but it's quite complex and there are complex interactions between ThreadUI and Compose. That's part of the reason I want to do this: to simplify this.
    (Oleg) got it, and what about "some MADAI work"? Is it dependency for other bugs?
    (Julien) yes, one moment: https://bugzilla.mozilla.org/show_bug.cgi?id=1026384
    (Julien) in this bug, we need to switch to "MMS" when the user adds a "email" recipient. This is not easy at all with the current architecture.
    (Oleg) Ok, so it sounds like p=2 at least
    (Julien) yeah, I can't choose between 2 and 3.
    (Oleg) then 3 :)
    (Julien) ok. Then we're finished :)
Retrieved from "https://wiki.mozilla.org/index.php?title=Gaia/SMS/Scrum/2.0S6/Planning&oldid=995098"