Gaia/SMS/Scrum/2.2S4/Planning

Sprint is from 6 Jan -> 26 Jan (called 2.2S4) Velocity: [p=7]

(Julien): I'd like that we use 0 for me, even if I'll still pursue the gaia-header patch.

(Julien) holidays or day off or ideation groups for you ?

(Oleg) No holidays, but ideation group takes some time for me.

(Steve) As same as Oleg

(Julien) how much time, would you say ? half of time ?

(Oleg) For me it's 20% or 30% as max.

(Steve) Maybe 6~8 points for this sprint? I can have half time on this

(Julien) Let's say 6 points, that's what I calculated too. With 2 or 3 points more for blockers? Or maybe ditch blockers for this sprint (this can wait) and take 8 points full for feature-b2g (I mean perf :) ) ?

(Oleg) Can we ignore blockers right before branching? :)

(Steve) Maybe, it's not code freeze yet(for 2.2),

(Julien) David always said that before freeze, features are most important :) rationale is that we can always do blockers later, but no features. Moreover perf related stuff is more risky, better do it first. That said we have 2 weeks in the sprint that happens after branching, so we can take some blockers.

(Oleg) Ah ok, makes sense.

(Steve) Not sure if 2.0m is important for us. Did you been bothered by Josh frequently? :)

(Oleg) Nope, mainly proactively worked on this and bothered Josh if need help :)

(Julien) there is no 2.0m blockers right now, anyway ?

(Steve) No blocker for 2.0m right this moment, just in case that we'll need some cycle on this

(Julien) ah ok, get it. Yeah, we can maybe keep 1 point for this, and take 7 points for the sprint's velocity ?

(Steve) Ok for me

(Oleg) Sounds good for me too

(Julien) so... next :)

Focus for this sprint is feature-b2g, which are all perf-related.

From current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=1112131 [skip]
Bug 1112131 - [header] Propose a start and end attributes to hint the component about the left and right offsets

(Oleg) This one in review already, Julien do you expect it to land soon or not? Looks big

(Julien) This week, likely tomorrow, but...

(Oleg) Should we skip this one too? Do you have anything related that we can help with and include in the sprint?

https://bugzilla.mozilla.org/show_bug.cgi?id=1089920 [skip]
Bug 1089920 - [Messages] Investigate and fix the gaia-header in Messages app

(Julien) Not a lot of work left: first bug needs to polish the patch, second bug needs to adapt to latest changes. Possible perf-related follow-up is how/when we inject internal content in the web component.

(Julien) if I work on this out of the sprint, should we skip it ?

(Oleg) I think we should skip it in this case +1

https://bugzilla.mozilla.org/show_bug.cgi?id=1091441 [p=?]
Bug 1091441 - [Messages] the thread view is flashing while loading if there are MMS

(Steve) Will give it a try with taskRunner idea, should have some result today.

(Julien) I think we should pursue this even if it's not a "perf" feature. But maybe in 2nd priority?

(Oleg) Yeah, the issue is quite annoying and noticeable

(Steve) Ok for me, we can revisit it later if we still have points remain.

blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1116780 [p=1]
Bug 1116780 - [Messages] We should not focus the composer after clicking a notification

(Julien) there is a WIP patch, one missing "resolve" in the patch + tests

(Oleg) 1 point for me, if we include it in sprint of course.

(Steve) p=1

(Julien) good for me !

(Julien) OK that one of you finish it from my WIP patch?

(Oleg) Sure, I can take it

nominations

https://bugzilla.mozilla.org/show_bug.cgi?id=1091511 [skip]
Bug 1091511 - [Flame][v2.1][Message]The number/email or URL can't be tapped if there is full-width text in this message

(Julien) "should" not take too much points, but this part is always tricky.

(Julien) IMO should skip it.

(Oleg) Let's skip

(Steve) Skip+1

features

https://bugzilla.mozilla.org/show_bug.cgi?id=1087981 [p=1]
Bug 1087981 - [Message] Lazy init settings in notify.js

(Julien) not much left to finish it IMO. I'm not sure it will improve first panel rendering (because this script is lazy loaded after first panel) but it will improve whole rendering.

(Julien) IMO p=1

(Oleg) Sorry, could you please just give me a very short description why lazy loading this file will give a sensible improvement? Can't get it from wip :(

(Julien) mainly accessing mozSettings is costly :) so eliminating line 10.

(Steve) It looks ready(and I already reviewed it few months ago), p=1

(Julien) yeah, one test is missing

(Oleg) Okay p=1, initially I was thinking that we can use this bug to lazy load other things that may affect perf, but we can use "More perf improvements" bug for this.

(Julien) yes, not really the goal of this bug; notify.js is already lazy loaded :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1089154 [p=1]
Bug 1089154 - [Messages] investigate scoping CSS rules

(Julien) first step is to remove last/first/nth-child/nth-of-type/etc pseudo selectors and see if there is an improvement. If there is an improvement look if we can scope some of the rules, or replace them where appropriate.

(Steve) Do we need to compare the performance of replacing the pseudo selectors/ scoping the pseudo selectors? Since you already have a patch for scoping the css

(Julien) I can see one issue with scoping: we currently need a nth-child in thread list. So this one can't be scoped for sure. But I'm not sure it's costly :) I think we should first remove everything to see if this improves; if nothing improves then it's not that costly ;)

(Steve) Ok, maybe 1 point for testing first? If it did work then we can decide what we should do.

(Oleg) Yeah, I think it the way to go, even bug is about investigating only

(Julien) I'd say ok, unless we'd want to land this in v2.2. But maybe we can ask approval after branching?

(Oleg) Why not? I'd say perf improvements are like blockers +1

(Julien) OK then, p=1 for at least know if this is a likely improvement.

https://bugzilla.mozilla.org/show_bug.cgi?id=1109754
Bug 1109754 - [Messages] Consider using a queue to render threads at startup

(Julien) I didn't see much improvement with this (likely because the gecko API fetch in chunks now). Might want to run test-perf with/without the patch with RUNS=50 to have actual numbers? (note: I use http://mathjs.org/ to calculate median of values, this is more meaningful than average)

(Julien) I'd skip this in favor of other perf improvements in next bug, given my previous findings;

(Oleg) agree

(Steve) skip

https://bugzilla.mozilla.org/show_bug.cgi?id=1087329
Bug 1087329 - [messages] More perf improvements

(Julien) identify other points of improvement (ex: ThreadUI (even if it's not in critical path), date_time_helper).

(Julien) What do you think? Should we have 2 bugs: ThreadUI and date_time_helper ?

(Oleg) tbh I don't feel comfortable to create this bugs now until we know that it may improve something, maybe have some points for this bug and split it to "child" bugs when we identify them during sprint, don't know really

(Julien) I'm sure we can improve things (especially for ThreadUI), but I don't know how ;) date_time_helper is more tricky because it's part of /shared. Same issue than notify.js: access to mozSettings :)

(Oleg) Did they want to get rid of it for v2.2 in favour of Gecko implementation?

(Julien) I really don't know, would be nice.

(Oleg) Currently I'm thinking about mozSettings and mozContacts that can be slow... So how many points we have?

(Julien) 4 points left

(Julien) about ThreadUI.init: we do a lot of things in it, like initialize AttachmentMenu, Composer, so we might want to delay some of it to beforeEnter.

(Steve) Refactoring ThreadUI is nice, I also want to shave more code from ThreadUI :p So we want to put points on different parts?

(Oleg) Yep I think, just want to identify something actionable and valuable :)

(Oleg) So what we can do for sure? Don't (lazy) load composer-only stuff for thread and vice versa?

(Julien) we need to measure each line of ThreadUI.init to know what takes time for sure, and move it elsewhere :) I think it's a p=2 task for this (investigate + move what needs to be moved + tests). I use console.time/console.timeEnd to test this, works fine from WebIDE or even running inside Firefox (even if in Firefox it's obviously faster :) ).

(Steve) It seems not a trivial one, maybe p=3 for all the jobs?

(Julien) IMO it's easy but maybe because I'm used to it :) p=3 for ThreadUI only? or p=3 for looking at other perf pain points + Thread UI + date time helper ?

(Steve) I think there is still some room for ThreadUI, might worth 1 point to figure out how many things we can improve.

(Julien) On this week, I think we need to focus on doing the most perf improvement with the smallest change, that's why I outlined earlier to only move whatever takes time out of init to beforeEnter (or improve maybe the operation itself that takes time, or both). That's why I think it's only p=2 because we don't want to do too much refactor. Also ThreadUI.init is not in critical path, I think, but date_time_helper is, so we can also decide what to look at first. Maybe p=1 to decide what to look at first, and then p=3 to work on what we found?

(Steve) If date_time_helper is critical, maybe we can put p=2 on it first and p=1 for other investigation?

(Julien) yep but I don't know how we can improve date_time_helper TBH :/ We need the information to render the times in ThreadListUI. Or can we rerender the times later when mozHour information is resolved correctly?

(Steve) Then we will need another investigation on date_time_helper... to see if it worth to delay the date/time on ThreadList and Jenny is comfortable about this change.

(Julien) and maybe ask whoever needed to implement in Gecko if this is happening soon.

(Julien) I'm fine with p=2 on date_time_helper and p=1 for more investigation, p=1 for ThreadUI. But we see that we're going nowhere with date_time_helper we can be proactive and stop earlier.

(Steve) Fine for me, or we simply put p=1 on both for investigation and action in next sprint. Maybe Oleg have other thought?

(Julien) again I'd like that we work on this before next sprint, so that's why I'm insisting much ;)

(Oleg) Why can't we get p=1 first for investigation (inlcuding ping Gecko devs on moz12Hours to know whether we need further actions on it) and then we'll have 3 points to do actual things this sprint, or you think p=1 isn't enough to outline the work we need to do? My main concern (personal) is that I don't know what we should do before we investigated it

(Julien) well we at least know about date_time_helper and ThreadUI, but we can investigate for more, or to know the important things (like is it happening before/after lazy loading).

(Oleg) I mean, have we already measured it and know that ThreadUI.init takes a lot of time, sorry if I missed that :( Regarding to date helper (if we'll still have to live with that shim), the only thing that I can think of (that doesn't affect UX) is lazy load it right before first usage only.

(Julien) see comment 6 in the bug :) Okay, sorry :)

(Julien) lazy load it right before usage, that's what I said earlier: because we need it in ThreadListUI, and ThreadListUI is in critical path... maybe that's something we'll need to live with.

(Julien) I'm fine with the plan outlined earlier: p=2 for data_time_helper (if we can do something, stop early), p=1 for investigating if there is something big in critical path, p=1 for ThreadUI.init.

(Oleg) Let's try :)

(Steve) +1

(Julien) good, I'll create the individual bugs :) Finished then !

(Oleg) Thanks!