Gaia/SMS/Scrum/2.0S6

List of bugs

SMS issues handled by the SMS subteam (blocks the sprint bug 1035283)

Bugzilla link

Full Query

ID	Assigned to	Summary	Blocking b2g	Feature-b2g	Whiteboard	Resolution
944249	Julien Wajsberg [:julienw]	[Messages] move the segment information request and size check to compose.js	---	No cf_feature-b2g	[p(2.0S6)=3][p(2.1S1)=2]	FIXED
985273	Oleg Zasypkin [:azasypkin]	[DSDS] SIM labels of missed calls & sms in Notification is different	---	No cf_feature-b2g	[sms-most-wanted][p=1]	FIXED
1022575	Oleg Zasypkin [:azasypkin]	Received SMS store (without text) on check balance.	2.0+	No cf_feature-b2g	[p=2]	FIXED
1033260	Julien Wajsberg [:julienw]	[Messages] Contact suggestion list didn't dismiss when focus on subject(for all branches) and message input field(1.3t only)	---	No cf_feature-b2g	[p=1]	FIXED
1033403	Julien Wajsberg [:julienw]	[Messages] We don't stop rendering if we tap "back" too soon	---	No cf_feature-b2g	[p=1]	FIXED
1034600	Oleg Zasypkin [:azasypkin]	[Messages] Suggestions list is badly located	2.0+	No cf_feature-b2g	[p=2]	FIXED
1034633	Oleg Zasypkin [:azasypkin]	[Messages] subtle padding issues while manipulating the subject	2.0+	No cf_feature-b2g	[p=1]	FIXED

7 Total; 7 Open (100%); 0 Resolved (0%); 0 Verified (0%);

Remaining points and burndown chart

google chart api url for Sprint 2.0S6

	Remaining points
Start	11
Day 2	9
Day 3	9
Day 4	7
Day 5	7
Day 6	7
Day 7	7
Day 8	7
Day 9	3
Day 10	3
End	3

SMS issues handled by the SMS subteam outside of the sprint (with whiteboard "sms-sprint-2.0S6")

Full Query

ID	Assigned to	Summary	Blocking b2g	Feature-b2g	Whiteboard	Resolution
1009568	Julien Wajsberg [:julienw]	[Messages] Possibly remove the code with forceClean in ThreadUI.cleanFields	---	No cf_feature-b2g	[sms-sprint-2.0S6]	FIXED
1015390	Steve Chung [:steveck]	[SMS] Implement new startup loading events	---	No cf_feature-b2g	[c=automation p= s=2014.08.01.t u=][sms-sprint-2.0S6]	FIXED
1035279	Oleg Zasypkin [:azasypkin]	[Messages][Refactoring] Move error codes mapping from dialog.js to a separate file	---	No cf_feature-b2g	[sms-sprint-2.0S6][p=1]	FIXED
1039585	Oleg Zasypkin [:azasypkin]	[Messages][Refactoring] Implement EventDispatcher object	---	No cf_feature-b2g	[sms-sprint-2.0S6]	FIXED

4 Total; 4 Open (100%); 0 Resolved (0%); 0 Verified (0%);

All SMS issues tracked for this sprint (target milestone)

Bugzilla link

Full Query

ID	Assigned to	Summary	Blocking b2g	Feature b2g	Resolution
985273	Oleg Zasypkin [:azasypkin]	[DSDS] SIM labels of missed calls & sms in Notification is different	---	---	FIXED
1022575	Oleg Zasypkin [:azasypkin]	Received SMS store (without text) on check balance.	2.0+	---	FIXED
1033260	Julien Wajsberg [:julienw]	[Messages] Contact suggestion list didn't dismiss when focus on subject(for all branches) and message input field(1.3t only)	---	---	FIXED
1033403	Julien Wajsberg [:julienw]	[Messages] We don't stop rendering if we tap "back" too soon	---	---	FIXED
1034271	Pavel Ivanov [:ivanovpavel][:pivanov] UX	[SMS] Background graphic is out of date	---	---	FIXED
1034600	Oleg Zasypkin [:azasypkin]	[Messages] Suggestions list is badly located	2.0+	---	FIXED
1034633	Oleg Zasypkin [:azasypkin]	[Messages] subtle padding issues while manipulating the subject	2.0+	---	FIXED
1035283		[meta] SMS subteam sprint 2.0S6	---	---	WONTFIX
1039585	Oleg Zasypkin [:azasypkin]	[Messages][Refactoring] Implement EventDispatcher object	---	---	FIXED

9 Total; 9 Open (100%); 0 Resolved (0%); 0 Verified (0%);

Sprint planning

Minutes are on a separate page.

Daily meetings

Day 2: 9th July

Steve

• absent for military service for one week(7/5 ~ 7/11)

Julien

• Landed bug 1033260: we don't hide the "contacts suggestion list" when the user taps the subject input
  • the bug is 1.3t+ because steve found the problem to be bigger on Tarako, but I don't reproduce his findings, so I'm waiting for him before requesting uplift to 1.3t and 1.4.
  • got approved for v2.0, I'll uplift there myself
• bug 1033403: if we press "back" quickly, we still render messages
  • i waited for input from jenny. Now she gave it I'll be able to resume work on it!
• reviewed other madai bugs
  • one of them (quite simple) landed
  • another will wait for bug 944249 we took in the sprint
  • I have yet some more today

Today: move forward with jenny's and oleg's suggestion in bug 1033403 + possibly start working on bug 944249

Oleg

• bug 1027593 - [SMS] Error displaying long messages
  • QA provided video with the remaining 'blurry text' bug + they noticed some laggy behaviour in the text input;
  • Kats picked up the bug and now it's Core one and not Gaia::SMS anymore :)
  • Patches are in Mozilla-Inbound now!
• bug 1035279 - [Messages][Refactoring] Move error codes mapping from dialog.js to a separate file
  • Patch is ready, will play with it and once I have more time I'll ask for review.
• bug 985273 - [DSDS] SIM labels of missed calls & sms in Notification is different
  • Landed (landed).
• bug 1034633 - [Messages] subtle padding issues while manipulating the subject
  • Since container for the send button and message input is flex-box aligned to the start (top) and button is higher than input initially (4.5 rem vs 4 rem) we have a 0.5 rem gap below message input. At the same time subject input and counter label should be aligned and it's harder to do if elements below have different height. I've prepared the easiest possible patch for the fix (made send button and input have the same height of 4 rem) and asked UX review. If UX doesn't accept it, will try to find other solution;
  • Other than that I've used that bug as a chance to get rid of sprite (i.e. separate image for the send button disabled state) and use CSS power to have the same effect (using http://azasypkin.github.io/style-my-image/ :)).
• bug 1033260 - [Messages] Contact suggestion list didn't dismiss when focus on subject(for all branches) and message input field(1.3t only)
  • Reviewed master patch (landed) and tried to reproduce issue Steve noticed for v1.3t (no luck) (qa wanted).
• bug 1033403 - [Messages] We don't stop rendering if we tap "back" too soon
  • Reviewed once again with the latest changes, looks good except that we'd like (I think UX confirmed that) to mark thread as read even if user quickly left Thread panel.

Other:

• Added a bunch of Demo's to the wiki page for the Sprint 4.

Today:

• Will work on bug 1034600 - [Messages] Suggestions list is badly located
• Will handle review comments for the patches that currently in review;
• Also would like to think how we can deal with "bug 1034100 - [Messages] in some situations, the character counter overloads the send button" (couldn't do it yesterday)

Day 3: 10th July

Julien

• Landed bug 1033260: we don't hide the "contacts suggestion list" when the user taps the subject input
  • uplifted
• bug 1033403: if we press "back" quickly, we still render messages
  • proposed the latest patch following Jenny and Oleg's advice; not much more to say
  • was r+ by Oleg so will land later today
• reviewed all madai bugs that remained in my review list
  • one is nearly ready but need to fix a python test (bug 974864)
  • another is changing a lot of stuff so I had to dig in to see why and propose smaller changes (bug 982029)
• tried again to investigate bug 1029188 (wrong thread/good header when typing on the notification, in v1.3)
  • I looked at the code for v1.3, no lead so far
  • I'll try to reproduce with a similar set of data than the reporter uses (very small thread)
• Other:
  • worked on Travis stuff: fixes for mozilla-download and mozilla-get-url (bug 1033221) and the Makefile (bug 1033472)

Today: start working on bug 944249 + some more reviews to do from a long time ago + updated reviews from Madai

Oleg

• bug 1027593 - [SMS] Error displaying long messages
  • All required patches have been landed and I can't reproduce the issue on the latest PVT build (resolved, fixed).
• bug 1035279 - [Messages][Refactoring] Move error codes mapping from dialog.js to a separate file
  • Sent patch for review (in review).
• bug 1034633 - [Messages] subtle padding issues while manipulating the subject
  • Sent patch for review (r+'d, waiting for reply from UX).
• bug 1033403 - [Messages] We don't stop rendering if we tap "back" too soon
  • Reviewed the latest patch, looks good r+'d (checkin-needed).
• bug 1034600 - [Messages] Suggestions list is badly located
  • Investigated requirements for the suggestion list height, before patch for "bug 949457 - Make Compose into a flex layout" it occupied all space between "To:" field and keyboard, after this patch it now has a gap at the bottom (I was suspecting that it was made to uncover Send button, but will look into looong review discussion to better understand :) ). Found only one reference in the VDR mockups (https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8417859).

    (Oleg) Julien, maybe you remember why it was done this way?

    (Julien) Before that bug, we were calculating the height of the container after each keypress. And I think we were resetting it when we were in "composer" mode, so maybe that's the reason. Still it's painful that we use the same element.

  • Have patch in mind, hopefully will send it for review by EOD.

Today:

• • Will work on bug 1034600 - [Messages] Suggestions list is badly located
  • Will handle review comments for the patches that currently in review;

Day 4: 11th July

Julien

• bug 1033403: if we press "back" quickly, we still render messages
  • Landed
• tried again to investigate bug 1029188 (wrong thread/good header when typing on the notification, in v1.3)
  • tried to reproduce with the same data, nothing :(
  • I'll keep this bug open for now but won't do anything until I get a Open C.
• worked on bug 1036532 (1.4+): we don't have some background-images at the right resolution, and as a result it triggers a gecko bug for rounding pixels
  • I'll try to work with Arnau today to do these things right. I think my background-size was bad yesterday.
• started working on bug 944249: refactoring of Compose.type and send button handling
  • wrote the current call sequence on paper
  • threw some idea on paper
  • ready to start some code today !
  • I hesitated between making Compose instantiable or not; but after thinking, I'll keep it for later :)
• Other:
  • worked on Travis stuff: fixes for mozilla-download and mozilla-get-url (bug 1033221) and the Makefile (bug 1033472)
  • Monday is holiday in France, so I won't be here !

Today:

• reviews that I left yesterday (still madai, + sms stuff)
• investigate bug 944249
• continue work on bug 944249

Oleg

• bug 1034633 - [Messages] subtle padding issues while manipulating the subject
  • UX replied positively on reduced bottom padding for message input (landed).
• bug 1034600 - [Messages] Suggestions list is badly located
  • Prepared patch, it affected css rule used by contact lists in report and participants views, played with it - looks ok to me. So sent it for review (in review).

Today:

• Will handle review comments for the patches that currently in review;
• Will pick up next bug planned for the sprint (while current in review).

  • (Oleg) Julien, maybe we replace "bug 1024835 - [MMS] Receiver receive a garbage message when receiving a MMS if turn off auto retrieve mode" with "bug 1022575 - Received SMS store (without text) on check balance." since the former isn't blocker anymore and for the latter Gecko dep is resolved?

    (Julien) since we haven't started the second one, yeah, maybe we can do this. Will make managers happy and for us it's ok because we haven't started.

    (Oleg) Yep, btw do you know how to simulate "SIM with billing"? If not I guess I just need to trick with Cost control

    (Julien) you just need to configure your sim as "prepayed" SIM in cost control. Then you'll have the 'update' button in the app to update the current check. You can also ask marina (mai on IRC) for the exact SMS that needs to be received by cost control so that it understands it. Maybe needinfo on the bug so that we have a written information for later.

    (Oleg) ok

    (Julien) there is a file somewhere where you can configure phone numbers to send the mail to. Trying to find it... ok, in apps/costcontrol/js/config/config_manager.js, you force a config in getConfigFilePath (ex: 'vivo'). Then in vivo/config.js you can change the "balance' object at the end, "destination" is where the SMS is sent, "senders" is an array with expected senders for received SMS. So you can add your own phone number here.

    (Oleg) great, thanks for sharing!

    (Oleg) oh we didn't estimate bug 1022575, I suspect it p=2

    (Julien) yep me too

    (Julien) same than the other

• --- IRC reply from Marina ---

  • (Marina) First at all, you need to change the costcontrol config

    (Marina) Change the file apps/costcontrol/js/config/config_manager.js

    (Marina) change the line 113 https://github.com/mozilla-b2g/gaia/blob/master/apps/costcontrol/js/config/config_manager.js#L113

    (Marina) by return 'js/config/vivo/config.js';

    (Marina) On the file apps/costcontrol/js/config/vivo/config.js

    (Marina) change the line 108 https://github.com/mozilla-b2g/gaia/blob/master/apps/costcontrol/js/config/vivo/config.js#L108

    (Marina) and add to the array your mobile number eg senders: ['4850','+34123123123],

    (Marina) and add to the array your mobile number eg senders: ['4850','+34123123123'],

    (Marina) Enter on Costcontrol app and configure as prepaid

    (Marina) on the balance screen pulse the button update, with this the app os costcontrol send a message to the number defined on the line 104 of the file vivo/config.js -->destination: '4850',

    (Marina) This sms is one of the sms that costcontrol removed automaticatly

    (Marina) At this moment the app is waiting for a message, send a message with the following txt from the number reported on the line 108 of vivo/config.js

    (Oleg) everything is clear now, except "send a message with the following txt", what text should it contain?

    (Marina) 00000000000000000000000000000000OWD20140711085233011100102

    (Marina) this is the emitted sms

    (Marina) the received is like

    (Marina) 2014071108523301110010215.67;15/06/2014

    (Marina) the second text is the response

    (Marina) this is the sms that you have to send from the number defined as sender

    (Marina) 15.67 is the balance, if the sms is received correctly, you can see on the widget or on the balance screen the number 15.67

    (Marina) It's a little tricky, but unless you have a vivo simcard it's the only way

    (Oleg) cool, np it's ok, so, can I use the same text all the time to test or I'll have to update date components in it somehow ?

    (Marina) yes

    (Marina) the same text is valid

    (Marina) only if you want ensuere the text ir received correctly, you can change the amount ;)

    (Oleg) ) ok

Day 5: 14th July

Steve

• Read tons of mail
• bug 1033260 - [Messages] Contact suggestion list didn't dismiss when focus on subject(for all branches) and message input field(1.3t only)
  • Already fixed by julien, just need to provide video for v1.3t about the strange behavior
• bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
  • Here is a list for flame 273 MB memory limitation test http://mzl.la/1kxNjEv: QC is testing flame with 273MB memory limit. It looks like some oom kill issue while attaching the image. Message app might be killed before visibility change for saving the draft, but I could not reproduce it yet. Ni? QC qa.

    (Oleg) Can you please give a me a hint how to limit memory on my Flame, so I can try to repro too? And yeah, from video it looks like it was killed before visibility hidden event.

    (Steve) Sure!

    • 1) adb reboot bootloader
    • 2) sudo fastboot oem mem 273 // Set memory limit to 273MB, 0 is auto(default)
    • 3) sudo fastboot getvar mem // Check if memory is set correctly
    • 4) sudo fastboot reboot
    • Note: Maybe you can get rid of sudo if you could access: fastboot devices

    (Oleg) Cool, thanks!

Today:

• Hunting for other message issue
• Revisit proactive delivery/read report notification feature bug 933133 if no other serious blocker.

Julien

• Today is public holiday in France.

Oleg

• bug 1034600 - [Messages] Suggestions list is badly located
  • Replaced 'vh' units with with '%' + using documentFragment for the suggestion list rendering. Sent for the second review round(in review).
• bug 1035279 - [Messages][Refactoring] Move error codes mapping from dialog.js to a separate file
  • Updated PR with almost all review comments, discussing "enum" usage with Julien (in progress).
• bug 1022575 - Received SMS store (without text) on check balance.
  • Got reproduction steps from Marina (how to setup prepaid SIM and so on.);
  • Since this event maybe fired on both deleted thread and deleted message we should handle in different panels. Currently we use "direct dependency" approach (eg. MessageManager calls ThreadUI.onMessageDeleted), I don't really want to keep that dependency, so I'm thinking about smth like this (ThreadUI and ThreadListUI subscribe for deleted event eg. MessageManager.addEventListener('deleted') and reacts appropriately, MessageManager just needs to fire appropriate event). We'll need the same approach when datastore is available.
  • Working on handling "deleted" event (in progress).

Today:

• • Will handle review comments for the patches that currently in review;
  • Will work on bug 1022575.

Day 6: 15th July

Steve

• bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
  • I can reproduce it after playing the step for a while, but the repro rate is not high. Since app might be killed before dispatching the visibility changed event, not sure if there is any better way to prevent data lost. Setting a timeout to save the draft continuously might still have chance to lost the message. BTW "willReadFrequently" might let us acquire less memory, but it seems still have chance to face OOM kill problem anyway...
• bug 1038176 - SMS app launch latency regressed in v2.0
  • Still waiting for the reporter's reply because we don't know how he performs the profiling. But I still take 2 flame to compare side by side. The first visible thread time "seems" a little shorter on v1.3 ... :p But we defiantly need actual data to prove it. Another note is the app transition animation seems faster on v1.3, maybe it also affect the result visually

    (Julien) if v1.3 looks faster we need to see why :) v1.4 (bug 1002847) was faster so maybe we regressed something between v1.4 and v2.0.

Today:

• Hunting for other message issue
• Revisit proactive delivery/read report notification feature bug 933133 if no other serious blocker.

  (Julien) you can also have a look at bug 1011089 for Haida. (but the notification bug is also a good idea)

  (Steve) Ah, thanks! I also have another non-blocking issue about low-storage handling. But I think it's not that important for now.

  (Oleg) I'm working on error handling changes, probably it may have conflicts.. bug 1035279

Julien

• Reviewed some MADAI work
  • bug 982029: quite scary because it changes how senders are matched, but I try to make it as less scary as possible ;)
  • bug 974864: pick an email recipient from the contacts app; should be ready today, not really scary, but changes the activity we use to pick contacts; now we can specify which property we need from the contacts app (email or tel or both)
• Reviewed patches from Oleg
  • bug 1034600: the suggestions list is badly located; a change we want for a long time :)
  • bug 1035279: changes how the error codes are displayed; we don't agree on everything yet ;)

    (Oleg) :) Yep, I've left some question at github on namespacing, not sure how to do this for errors coming from MessageManager, but I'm fine with that idea, it would be easier to understand the source of error. I planned to use enums in DS wrapper, so maybe won't if we decide it's not good enough :) The rest of comments\suggestions are fixed. Bug is out of sprint, so we have time to think.

• worked on bug 944249: Compose.js needs to own the send button enabled/disabled status, and the segments information for SMS
  • I worked on the segments information for now, maybe I'll leave the send button enabled/disabled for another bug depending on how I make progress and how big the patch is :)
  • current status is: everything's broken ;)
• gave some arguments to remove the blocker status from some 2.0+ blockers: bug 1038176 for performance, and bug 1037661 for OOM condition with a low-memory Flame. (best way to resolve a blocker is to remove the blocker status :p)

Today:

• more reviews from everybody
• bug 944249

Oleg

• bug 1022575 - Received SMS store (without text) on check balance.
  • Have working patch without unit tests though, since I'm using new event_dispatcher here, I'll ask today for feedback.(in progress).
• bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded
  • Was investigating, looks like app is killed because of OOM before visibility change event is fired, so we don't have a chance to save draft for the message.
  • When I was switching to Home screen, transition was very laggy, UI was frozen for a moment, and and that moment logcat output OOM kill.

    (Julien) I know the System app had some bugs about "abusing" the will-change CSS property, which takes more layers and so more memory. Maybe that's one issue here (maybe not :) )

    (Oleg) Btw, we don't use will-change for now in SMS app? I'm just curious how it's beneficial for other FxOS apps.

    (Julien) Yes, we're using it for the panel transition. Maybe we don't use it correctly too, it might be a good idea to look at it. (for example maybe we need to remove it when we don't transition, and add it only before we'll slide)

Today:

• Will handle review comments for the patches that currently in review;
• Will work on bug 1022575.

Day 7: 16th July

Steve

• bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
  • It's still nominated for 2.0 :-/ not sure which step we should take for 2.0:
    • Sync to v1.3t that saving the draft continuously

      (Julien) maybe we should do this anyway, yep. We fixed bug 1015194 in v1.3t too (in the draft patch itself, I think) because we saved invalid recipients, maybe we'd need this too.

    • Saving the draft right after image attached
    • Try anything else to reduce memory usage

      (Julien) What's strange is that we don't have this issue in Buri as far as I know, and Buri is 256MB I think?

      (Steve) Yes, it's 256MB, not sure the impact of device resolution. Another note is the software memory adjustment to 273MB might not a correct way for testing... I've heard that QC using another way for device setup and verify. Will update when I got a clear answer.

      (Julien) Yes, possibly. This is still a valid target but this may make the bug out of the blocker list.

• bug 1038176 - SMS app launch latency regressed in v2.0
  • No update yet.
• bug 933133 - [Gaia][Messages] Handling proactive notification while message report return
  • Raise a visual question for Jenny, and re-implement the previous patch for activity handler refactoring .

Today:

• bug 1037661: Trying any possible method to avoid the data lost
• Create a patch for bug 933133
• Revisit the sms feature backlog

Julien

Mostly the same than yesterday:

• Reviewed some MADAI work
  • bug 982029: changes how senders are matched, should be ready today if all tests are green this time
  • bug 974864: pick an email recipient from the contacts app; ready for SMS, waiting for a last contacts review
• Reviewed patches from Oleg
  • bug 1034600: the suggestions list is badly located; probably the last review today ? :)

    (Oleg) it should! :)

  • bug 1035279: changes how the error codes are displayed; left it out for yesterday because it's out of sprint, will look at it today once more
• worked on bug 944249: Compose.js needs to own the send button enabled/disabled status, and the segments information for SMS
  • I worked on the segments information and message type; I think I ironed out most cases, but now I need to hook up the recipients changes.
  • The button's "disabled" state should be easier to handle once I have the other pieces of information
  • I tried to write unit tests while writing code, but I know some existing unit tests will need to be modified/moved from ThreadUI
  • current status is: everything's broken ;) I hope to have something woking today, and a first reviewable patch for tomorrow. Otherwise I fear this will slip out of the sprint (unless my patch is perfect ;) ).
  • considering taking Oleg's event_dispatcher, but not sure since I think madai will want this in v2.0 for their email work. So maybe better to keep the dependency count low.
• bug 1037661 is a blocker again (the OOM condition on the Flame); maybe Steve can investigate? I'm still trying to move it out of the blocker list.

Today:

• more reviews from everybody
• bug 944249

Oleg

• bug 1022575 - Received SMS store (without text) on check balance.
  • Prepared very simple v2.0 patch that should fix original issue, no more no less (in review).
  • Made a bunch of improvements in event_dispatcher in master patch, wrote unit tests, almost ready, playing with it right now (in progress);
  • Made some very basic testing on Flame (literally with clock: )) of old thread deletion code and the one that deletes thread messages in batches: for the heavy work load (181 threads) full deletion with current code took about ~110 sec, with deletion in batch ~35 sec.

    (Julien) good news ! Doug will be happy :)

    (Steve) Nice!

    (Oleg) It's still 181 calls to MessageManager.deleteMessage, but not sure whether we can pass message ids for all threads in one call.

    (Julien) I don't see why we couldn't? Or at least we should try and measure.

    (Oleg) I've tried but didn't notice much improvements, but will try precisely. IMO it just too big array :)

    (Julien) one fear with mutliple calls is to have several "deleted" events...

    (Oleg) With batches, Gecko will fire only 181 events

    (Julien) yep :) maybe 181 vs 1 does not make much difference, especially that the data is the same size in the end

    (Oleg) yeah, that what I wanted to say :) There is difference when we call 181 vs 181* number_of_messages_in_thread

    (Julien) :D

    (Steve) I think it worth to give it a try

    (Oleg) yeah, I have this in my current patch, but will try with only one call instead of 181 and see the difference. It was late yesterday, but I didn't notice much improvements :)

• bug 1034600 - [Messages] Suggestions list is badly located
  • Fixed latest review comments and sent for review again (in review).

Today:

• Will handle review comments for the patches that currently in review;

Day 8: 17th July

Steve

• bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
  • Ongoing, will saving the draft continuously and saving the draft after image attached in first approach.

    (Julien) Maybe assign yourself to the bug if you work on it?

• bug 1038176 - SMS app launch latency regressed in v2.0
  • Update with a side by side comparing video and will provide my profiling later. Unfortunately the latency actually existed :( . Comparing with master and v1.3, we will have around 500ms delay from dom loaded to first view rendered

    (Julien) from the Video it looks like there is a first latency in homescreen, right ?

    (Steve) Yap, I think so, but we might also have something that cause the latency in our app.

    (Julien) oki. Next is to profile then...

• bug 1015390 - [SMS] Implement new startup loading events
  • A small patch for using the new window load events
• bug 933133 - [Gaia][Messages] Handling proactive notification while message report return
  • Patch submitted and some feedback return. Might need promise for further wrap up(And also waiting for UX about the notification layout)

Today:

• bug 1037661: Trying any possible method to avoid the data lost
• Create a patch for bug 933133
• Revisit the sms feature backlog

Julien

• Reviewed some MADAI work
  • bug 982029: changes how senders are matched, r+ yesterday but I'll have a last look before merging today.
  • bug 974864: pick an email recipient from the contacts app; ready for SMS, waiting for a last contacts review (still waiting for Francisco, will ping him)
  • I know there is a last big bug that will come but for now I don't have other MADAI reviews, this will free me some time :)
• Reviewed patches from Oleg
  • bug 1034600: the suggestions list is badly located; r+
  • bug 1035279: changes how the error codes are displayed; left it out again ;) will really try to look at it today
• investigated bug 1029188: when tapping the notification, the wrong header is displayed (in Open C v1.3, shipped). I found that our partner uplifted a patch to v1.3 without uplifting regression fixes...
• could not work on bug 944249 :( Main difficulty right now is to know when to stop refactoring :) For example I don't know if we should move the segmentInfo display to compose.js or keep in thread_ui.js; I think it should eventually move but maybe not right now?
  • I'll file some follow-up bugs about separating the concerns more, but I'll probably don't do everything yet. :)

    (Steve) I would prefer smaller patch that easier for review :p But yes maybe segmentInfo should belong to compose.js eventually.

Today:

• some small reviews
• definitely bug 944249

Oleg

• bug 1022575 - Received SMS store (without text) on check balance.
  • Added review nit in the main patch and sent it for review (in review).
  • Split previously planned master patch into two that will be landed in the scope of different bugs (one for event dispatcher only, second on for thread "batch deletion").
  • Confirmed that difference between 181 vs 1 delete call is insignificant.
• bug 1034600 - [Messages] Suggestions list is badly located
  • Got r+, adding some assert comments into the unit tests and will land it (checkin-needed).
• bug 1039585 - [Messages][Refactoring] Implement EventDispatcher object
  • EventDispatcher patch that mentioned above (in review).
• bug 1038176 - SMS app launch latency regressed in v2.0
  • As Steve noticed there is latency in SMS app, will investigate if Steve don't have much time by EOD, otherwise won't touch it. Unfortunately don't have two flames to make side by side, so profiling only.

Today:

• Will handle review comments for the patches that currently in review;
• Want to try to split datastore requirements into smaller tasks.
• If patch for bug 1022575 is landed today, will file next bug for thread "batch deletion", otherwise will wait for this and event dispatcher patches.

Day 9: 18th July

Steve

(in PTO today)

Julien

• Reviewed some MADAI work
  • bug 982029: changes how senders are matched, landed
  • bug 974864: pick an email recipient from the contacts app; landed
• Reviewed patches from Oleg
  • bug 1035279: changes how the error codes are displayed; still couldn't look yesterday, and I won't be able to look at it today probably. I want to answer your queston still...
• bug 944249: move the send button and segment info management to compose.js
  • I have a working patch, now I need to update unit tests (and move some of them)
  • I'm separating it in logical commits and making separate bugs when it makes sense
  • After thinking more, I want to use the new event_dispatcher in this patch
• Followed up on the bug 1038176 (launch latency in v2.0), bug 1037661 (mms discarded if pressing home while resizing), bug 1036868 (tarako specific, the notification for MMS does not appear sometimes when playing video/audio... can't reproduce myself), bug 1040020 (tarako-specific, launch latency, especially when tapping the notification)

Today:

• review for event_dispatcher
• try to have a final patch for bug 944249 so that Oleg can start reviewing today
• absent this afternoon

Oleg

• bug 1022575 - Received SMS store (without text) on check balance.
  • Landed 2.0 patch (landed)
• bug 1034600 - [Messages] Suggestions list is badly located
  • Landed (landed).
• bug 1039585 - [Messages][Refactoring] Implement EventDispatcher object
  • Update patch with review comments ("trigger" renamed to "emit", using {listeners: Map} as context for the dispatcher methods) (in review).
• bug 1038176 - SMS app launch latency regressed in v2.0
  • Reading the latest comments from Steve and Vicamo, doesn't look like we can do anything from SMS side. What do you think?

    (Julien) I'll add logs to measure things at various moments; I want to check why Vicamo and Steve find different things...

• bug 898364 - Moving conversation thread database from Gecko to Gaia by introducing DataStore API
  • Investigated how we can handle message events (onSend, onRead and etc.) via DS, left comments about it at etherpad;
  • Left some comments in Tasks section + small draft description on MessagingManager I have in mind. Please take a look and give your feedback :)

    (Julien) will have a look !

Today:

• Will handle review comments for the patches that currently in review;
• Will review patches for "bug 1040215 - [Messages] Move initSentAudio out of enableSend" and "bug 1009568 - [Messages] Possibly remove the code with forceClean in ThreadUI.cleanFields"
• Will work on extracted thread "batch deletion" patch once EventDispatcher patch is landed.

Day 10: 21th July

Steve

• bug 1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded.
  • Ongoing, will saving the draft continuously and saving the draft after image attached in first approach.

    (Julien) they say it crashes when we press home while resizing; so will you save the draft before resizing? I hope it won't make the process slower...

    (Steve) Yap, I planed to to so, otherwise we don't have any chance to save the image to draft

    (Julien) also, maybeit crashes at that moment because of the Homescreen's memory usage? I think there is a separate bug about this (can't find it now)

• bug 1038176 - SMS app launch latency regressed in v2.0
  • Update with some profiling result, it seems some regression in mozMobileMessage api(Vicamo is investigating on this part)

    (Julien) just want to know if you need something else from us? I can try to add some logs with timestamps just to double check what you found. Or have you looked at it with Vicamo already and he's investigating?

• bug 1015390 - [SMS] Implement new startup loading events
  • Patch updated, some question for Eli but should be able to land today

    (Julien) Eli answered :)

• bug 933133 - [Gaia][Messages] Handling proactive notification while message report return
  • Pending. Maybe we don't need it :p

    (Julien) There is something we don't do yet, I think: update the report panel if the message delivery/read notification return. We do update the thread view, but not the report panel.

    (Oleg) Don't we call "ReportView.onDeliverySuccess(e.message);" in message manager?

    (Julien) maybe my mind is outdated here, I'll double check

    (Oleg) Ok, I'm migrating this direct call to subscribe\publish

    (Julien) yeah, I know you're looking at this now :) so you're likely right :)

• bug 1041303 - [Tarako][SMS][Notification] Long delay between tapping the new SMS notification in utility tray and displaying the SMS
  • Still profiling. When music is playing at foreground, cpu will reach up to 80 or even 90%, and the system message with tremendous delay while cpu is high(some other action will also got penalty the high cpu usage, like app getself or even mobile message API). When we move the music to background, all latency for every action could be reduced to half or more. So maybe we can propose to move foreground app to background when system need to handle notification event.

    (Julien) looks like your investigation here is for bug 1036868 ?

    (Steve) Not really, but I actually faced notification lost while testing

    (Julien) in bug 1041303 they don't say Music is foreground

    (Steve) Yes, they do(In the second scenario). But I didn't see serious delay in the first case.

Today:

• bug 1037661: Trying any possible method to avoid the data lost
• Create a patch for bug 933133
• Revisit the sms feature backlog

Julien

• Reviewed patches from Oleg
  • event dispatcher: bug 1039585
  • bug 1035279: changes how the error codes are displayed; I should have the time today; I added a NI for me because otherwise I keep forgeting.
• bug 944249: move the send button and segment info management to compose.js
  • still working on updating unit tests. Should be finished today but I doubt we can finish it completly before end of sprint.
• various performance bugs:
• bug 1038176 (launch latency in v2.0)
• bug 1037661 (mms discarded if pressing home while resizing)
• Tarako specific:
  • bug 1036868 (the notification for MMS does not appear sometimes when playing video/audio... can't reproduce myself)
  • bug 1040020 (launch latency, it's not more than on other branches)
  • bug 1041303 (launch latency when tapping the notification; possibly because Cost Control is starting in the same time)
• reviewed a change to the icons (requested by Visual Team): bug 1021276
• reviewed the performance test events from Steve: bug 1015390

Today:

• bug 944249: finish unit tests, use event_dispatcher for the new events
• prepare tomorrow's sprint planning
  • especially look at haida and datastore etherpad and file new bugs for needed items

Oleg

• bug 1039585 - [Messages][Refactoring] Implement EventDispatcher object
  • Added support for "allowedEvents" to EventDispatcher, got r+ (landed).
• bug 1009568 - [Messages] Possibly remove the code with forceClean in ThreadUI.cleanFields
  • Reviewed, r+'d (checkin-needed).
• bug 1040215 - [Messages] Move initSentAudio out of enableSend
  • Reviewed, code looks good, but seems that with patch we can get into situation that sent audio won't be played for "Resend message".

    (Julien) good point !

• bug 898364 - Moving conversation thread database from Gecko to Gaia by introducing DataStore API
  • Waiting for your feedback on DS etherpad guys :)

    (Julien) will have a look !

• bug 1041124 - [Messages][Refactoring] Make use of EventDispatcher in MessageManager
  • My side work for the last day of this sprint and next one if I have time, have draft patch. This should make transition to DS smoother as all direct dependencies to UI components will be replaced with dispatched events.

    (Julien) we should make this part of the sprint instead of being a side work :) as part of our feature work for v2.1.

    (Oleg) Ok, even better :)

• other:
  • Added some demos to wiki page :)

Today:

• Will handle review comments for the patches that currently in review;
• Will work on bug 1041124 and probably will pick up something new from the most-wanted\2.1 features.
• Will work on extracted thread "batch deletion" patch once EventDispatcher patch is landed.
  • (Oleg): haven't worked on it yet, probably will continue once I finish bug 1041124.

Demos

bug 1022575: Received SMS store (without text) on check balance.

• 

  Before

• 

  After

bug 1033260: Contact suggestion list didn't dismiss when focus on subject.

• 

  Before

• 

  After

bug 1033403: We don't stop rendering if we tap "back" too soon.

Before patch for this bug messages could be rendered inside wrong thread.

• 

  Before

• 

  After

bug 1034600: Suggestions list is badly located.

• 

  Before

• 

  After

bug 1034633: Subtle padding issues while manipulating the subject.

• 

  Before

• 

  After

• 

  Before

• 

  After

• 

  Before

• 

  After

bug 985273: SIM labels of missed calls & sms in Notification is different.

• 

  Before

• 

  After

Retrospective

Previous sprints' actions

• invite all people that work on SMS to daily meetings (this time, we were missing Pavel, Marina)
• better identify that bugs will target the same area (eg: composer bugs); ideally we need to span them on several sprints, so we need to identify well in advance
• Try harder to take only actionable and clear bugs
• define what the scrummaster role is/should be (not for this sprint though)
• estimate quality metrics only once every 3 sprints.

What was good in the last sprint

• We dealt with significant amount of blockers;
• I had chance to work on DataStore related tasks;
• Looking back I'd say we're constantly improving our estimations + not taking non-actionable\not-clear bugs proved to be right.
• We didn't ifinish the sprint but it was close :) It's probably the best burndown graph we have so far !

What was bad in the last sprint

• Didn't finish sprint;

  (Julien) possible reasons? We took more than 10 points and our velocity was really 10; the remaining bug was more than 3 points.

  (Oleg) I think we took not really clear thing, it was actually harder and needed more tasks to be extracted from it. I mean segmentation info bug. Probably if we put p>3 it should be kind of flag about splitting the work.

  (Julien) yep, and as we discussed even p > 2 coud be a flag ;)

  (Oleg) yeah :)

• Panic with performance regression bugs. Reporters used unclear type of measurements, late Tarako bugs (I saw this lag between tap on notification a while ago), late low-memory-flame bugs. Maybe we need single\clear entry point for the reporters for correct measurements, Eideticker, datazilla and so on ... to avoid throwing ni? back and forth and wasting time.....

  (Julien) we can report this issue to the bigger retrospective. Not sure we can do better because most of the time the partners are reporting these bugs and it's difficult to educate them.

  (Oleg) Yep I understand, I mean probably on every performance bug we can answer first with a link about all these measurements, how to do it correctly and so on. Not sure whether it will help though

  (Julien) They have their own measurements, and that's what they want. Hopefully with the performance framework we'll get also a common ground.

  (Julien) our best action is to improve the launching performance in v2.1 :)

  (Oleg) Sure!

• (Steve) Unreasonable request from partner: We actually spend too much time in the late of cycle, but even the our release management could not prevent us from these request. We all knows the it's not possible to resolve these in few days(and we don't want some tricky workaround on specific branch), but we still have to do so.

  (Julien) bug https://bugzilla.mozilla.org/show_bug.cgi?id=1040020 is a good example of this. For now I pushed back and I hope it won't be made an urgent blocker...

  (Julien) is there anything we can do? Or should we report this to the bigger retrospective?

Any questions

• [not-part-of-initila-sprint]: I'm not happy with how this works; when we add in a next sprint a work that started in the previous sprint like this, it's not easy to distinguish. How about using (eg) [sms-sprint-2.1S1] in the whiteboard without adding the dependency, to say "we started this in this sprint" ? Or if we didn't finish it, just remove the sprint's dependency?

  (Steve) ya, I prefer the flag the specific sprint. It woud be clear for tracing.

  (Oleg) Agree that currently it doesn't work well, but don't have other ideas currently, so open to try anything new :)

  (Julien) let's try [sms-sprint-XXX] (same name than the alias for the sprint bug) then, and if we see later that we don't care about this information, we'll simplify further more.

  (Oleg) will we leave several these flags if bug is being resolved during several sprints?

  (Julien) yep; and I think it's good to see it took a long time :) (should not happen if things go right)

  (Oleg) Yes

• Do we still need [sms-most-wanted] flag?

  (Julien) I like the fact that anyone of us can add it. I fear that "priority" needs a review from Wilfred or Wayne (but maybe it does not ?)

  (Oleg) mmm I guess there are some bugs that not user facing/related like refactoring, but I'd say it most wanted, not sure whether Wilfred is interested in such bugs..

  (Steve) I think they didn't utilize the priority flag, so I raise this concern...

  (Julien) I find it useful to see where a bug comes from in our lists. We can keep it a little more and ask again in a few sprints?

  (Steve) It's fine for me, just wondering if there is a clear way for tracing the important issue

  (Julien) for important issues that are neither blocker or features, I guess sms-most-wanted or priority is the same, the goal is to find it easily. But "sms-most-wanted" shows that the team wants it, while "priority" means that the owner wants it.

Actions for next sprint

• bugs that we take out of the sprint use [sms-sprnt-<number>] in their whiteboard.

Grades

(5 is very good, 1 is very bad):

Commited tasks vs Completed tasks

(Oleg) t=4 (Steve) t=4 (Julien) t=4