Confirm
820
edits
Changes
Created page with "==Minutes== == Minutes == * Date: 07/07/2014 * Location: irc.mozilla.org/#gaia-messaging and https://etherpad.mozilla.org/sms-planning * Attending: Oleg, Julien Velocity: 10 ..."
==Minutes==
== Minutes ==
* Date: 07/07/2014
* Location: irc.mozilla.org/#gaia-messaging and https://etherpad.mozilla.org/sms-planning
* Attending: Oleg, Julien
Velocity: 10 (ok?) Let's try with 10
===Bugs from current sprint===
* https://bugzilla.mozilla.org/show_bug.cgi?id=985273
*: (Julien) needs a new review but should be quick => p=1 for me
*: (Oleg) p=1
* 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=1033403
** needs some nit to be fixed; likely won't be fixed completely today so we should take it into the sprint
*: (Oleg) yeah, it's important, but I think still p=1
*: (Julien) p=1 for me too
* 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===
* 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 then :)
* 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===
* https://bugzilla.mozilla.org/show_bug.cgi?id=1015390
** requested by performance team
** goal is to rename some existing performance events, and add new ones
** performance team wants this in 2.0
*: (Oleg) To be honest, the difference between all this events it's not really clear for me right now
*: (Julien) context is https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Testing/Gaia_performance_tests
*: (Julien) the goal is to put some markers at specific moment while the app is loading
*: (Julien) I think we should take some haida work instead, especially that we already have some markers so I think it's good enough. I can ask Eli if it's good enough for him.
*: (Oleg) One more useful (I think) link https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head
*: (Oleg) Yeah, agree on that
*: (Julien) we can take it in the end if we have time and they give some pressure
*: (Oleg) Yep, I see SMS is not the only one who didn't do it :)
===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 :)
== Minutes ==
* Date: 07/07/2014
* Location: irc.mozilla.org/#gaia-messaging and https://etherpad.mozilla.org/sms-planning
* Attending: Oleg, Julien
Velocity: 10 (ok?) Let's try with 10
===Bugs from current sprint===
* https://bugzilla.mozilla.org/show_bug.cgi?id=985273
*: (Julien) needs a new review but should be quick => p=1 for me
*: (Oleg) p=1
* 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=1033403
** needs some nit to be fixed; likely won't be fixed completely today so we should take it into the sprint
*: (Oleg) yeah, it's important, but I think still p=1
*: (Julien) p=1 for me too
* 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===
* 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 then :)
* 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===
* https://bugzilla.mozilla.org/show_bug.cgi?id=1015390
** requested by performance team
** goal is to rename some existing performance events, and add new ones
** performance team wants this in 2.0
*: (Oleg) To be honest, the difference between all this events it's not really clear for me right now
*: (Julien) context is https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Testing/Gaia_performance_tests
*: (Julien) the goal is to put some markers at specific moment while the app is loading
*: (Julien) I think we should take some haida work instead, especially that we already have some markers so I think it's good enough. I can ask Eli if it's good enough for him.
*: (Oleg) One more useful (I think) link https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#wiki-document-head
*: (Oleg) Yeah, agree on that
*: (Julien) we can take it in the end if we have time and they give some pressure
*: (Oleg) Yep, I see SMS is not the only one who didn't do it :)
===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 :)
