Calendar:Status Meetings:2006-10-18

From MozillaWiki
Jump to: navigation, search

<< previous meeting | index | next meeting >>

Meeting Details

Telephone Info

  • Toll free numbers
  • Access Code
    • 3646989
  • Conference controls
    • *6 mute line
    • *7 unmute line
  • Each time you say something, please say your name first so people know who's speaking

Agenda Items

  • Get final decision on version number for nightly builds so that we can sync mozilla1.8 branch and trunk bug 356725

0.3 Recap (carried over from last week)

  • Anything more to say on this?
  • What went right, wrong, otherwise?

0.5 Plans (carried over from last week)

  • Select target release date
  • Please take a look at lilmatt's list
  • State high level goals for 0.5 (we'll need to come up with them)

Meeting Log and Attendees

Attendees: ctalbert, lilmatt, jminta, ssa, sipaq, chis-j mickey, mvl, daniel Notetaker's note: Where I could tell who was speaking, I noted it. Where I didn't I left it off.

Updates on Download Rates

  • Sunbird: 54,342 since 0.3 release!
  • Lightning (via amo) 5045 Since 0.3 release!
  • To put in perspective total downloads for lighting is 17,647, so 34% of downloads have been since 0.3 release!
  • Can't get Lightning downloads from FTP because of an issue with release server (bug filed).

Decision on version number for nightlies

In a different bug, ssitter said that 0.4a1 would be fine b/c it follows the Tbird and ffox methodology. It also solves the sorting problem mvl: Next big release will be 0.5 then it will be much clearer that it will be after 0.4. If ffox uses it, then we can do it too.

  • Decided to continue using 0.4a1 although there won't be an real "alpha" release of 0.4. Next release still likely to be 0.5.

Recap of 0.3

sipaq: Localizers want test builds before the release. The first one they had was 0.3RC2, and that was too late. Probably could be addressed with L10N tinderbox.

lilmatt: We sent preed a list of what we need from #build, and they will get to that after they release firefox. We can probably also get by without that tinderbox in case the #build stuff doesn't work out by just planning it better.

  • We also need to develop from branch not trunk. We need test coverage earlier.
  • We didn't start cutting items soon enough and that was a problem.
  • We also had a lot riding on Joey and Joey went to law school. So next time, we need to make sure that the load is distributed more equally among all the developers.

jminta: What held us up at the end? What came in late in the game? Were those blockers or regressions or what?

lilmatt: Search for 0.3blockers without the plus and see what was closed, what was punted, that will give you a good idea.

sipaq: It should be said that it has been a great release so far. About 60K people have downloaded some form of it. Send me the download stats and I will post them to the blog or the newsgroup.

sipaq: One thing to add to 0.3 stuff, the respins for the two locales that we discussed last week. The Danish guy cannot build himself and will need a respin. Russian has minor typo's. Should we respin for simple typos or for unusable installer?

lilmatt: Unusable installer, we will respin. Only if there is something that makes it so that you can't use the product, then we'd respin. So probably not a Russian respin.

sipaq: Should we do a tinderbox, or should we build it ourselves, and have them test it and then submit as a contributed build?

lilmatt: the latter.

sipaq: I will do the contributed build to test their install. Got a note from a Sweedish guy who wants to do a localization. So that might be ready for a 0.5 release. That's another point of good news.


Next Version Discussion

Release Date

lilmatt: sipaq and I talked on IRC and they have decided that it will probably be around the end of December or sometime in January when we release the next version. So I'd like to propose Jan timeframe. Feelings?

ssa: Think about when all implementation details should be ready and when everything should pass QA. So is Jan the release date or the point at which it goes to QA?

sipaq: QA has to accompany the development all the time. From my experience, it doesn't work to leave qa at the end. You can see the results on the trunk, b/c all QA is done on branch.

ssa: That's assuming that the large features won't land too late. You could have QA all along and if the big features land too late, QA would still fall through the cracks.

ctalbert: We need to land large features sooner. There will be QA throughout the release cycle. We have gone to bi-weekly test days and Jminta and I are working on some regression strategies to help automate and expedite the testing.

?: Shouldn't we think first about what features we want to improve before we come up with the date? Drive the date by features?

lilmatt: That's another way of doing it. But we don't want to stuff too much development into the amount of time we're talking about. Why don't we use the idea of Mid Jan for RC1, while we discuss what features we want to implement. So, using that, we have a list that we have all the stuff that things that probably should be fixed in v.next

The List

lilmatt: First part of list are things that people have been reporting and complaining about. Second section is stuff we originally wanted to have but decided to punt on. So what of that do we want for this version and what do we want to punt on. Third part is mvl's original priority list from Toronto Meeting. Fourth part of the list is an organized selection of stuff that didn't make 0.3. There are a lot of things listed in several places on the list, but it seems like a good place to start from.

jminta: Need to work at a higher level for the 0.5 planning. Many of these refer to bugs.

lilmatt: We should probably start from mvl's list, and work down from that higher level like we did for 0.3.

  • Theme for 0.5 will be Collaboration
  • Theme for 0.7 will be UI and performance
  • Core Area:

ssa: Why should Core P1's go into later release (such as keyboard navigation)

ctalbert: Probably because things like that they be better suited to go in once the UI is more complete.

jminta: I think that all the priorities are for priority for 1.0, not priority for one component. The top level priority is priority for 1.0 but you can drop entire categories if you don't meet that priority. Gives example of places in firefox.

lilmatt: Changing to look at the list of things that didn't make 0.3. The priorities for these items came from mvl's original list and Joey's gut instinct, plus a call for feedback on the newsgroup.

ssa: Try to put those items into the gray list(mvl) and then see if it makes sense to work on those. Or shift them later. For instance, I think that adding printing to lightning goes along with the item to integrate lightning and thunderbird better.

lilmatt: I think a lot of those categories in the "stuff that didn't make it list" do match the items in the gray list. We just broke it down into more detail.

?: Looks like you could take the list of things that didn't make it in 0.3 and highlight those things in the gray list and that would help us to know what it's status is, and what amount of work is remaining.

ssa: Add a column of "when did the item get released" and writing release numbers to each line we will see what is required for 0.5, and then we can talk about it in the newsgroup

lilmatt: I'll do that. So we should look at the list and make sure that's still what we want to do for 0.5. Anything missing from Core on gray list?

Sipaq: Why do the views appear both in core and Views?

lilmatt: The data model and controller stuff would be core, while presentation is more UI, and that is why editing viewing appears twice. The 0.3 views item was more about working with the new views. and none of that stuff was cut. Polishing those views is not in 0.3 I think that's down in user experience further down the line.

Views

lilmatt: We know we are missing go to date functionality on lightning. dmose talked about zoom scrolling. I think that is ok to leave since Dan signed on to it. mvl: I am planning to do some view performance work, mostly by working on the storage provider.

ssa: We should communicate before we do something because we were also thinking about trying to provide an update mechanism in the provider so that if you want to update view periodically, it would be helpful if the provider could update you with just the set of changes since the last update.

lilmatt: There are several instances when you redraw/refresh all items and that could be improved. Wcap exposes the problem. Saw on Caldav and Google providers as well.

  • ssa and team will take the lead on provider related performance improvements.
  • mvl will also use indexes to help improve storage calendar performance. Might also work on caching for storage calendar but storage calendar must be fast first.
  • It makes sense for lilmatt's other schema change could also add those index changes as well, and we would only have one schema update.

Daniel?: We also need to look at how the recurrence events are read out of the storage calendar. Especially recurrence items with exceptions as well

  • Daniel and mvl will work together on storage provider related performance enhancements.

Moving on down the list...

lilmatt: Display of tasks: We know that the hide completed tasks bug is a priority in that area. We should fix the bug soon since lots of people have complained about it.

Christian: Work-flow - user experience. We need to think about a way to improve the overall ui. Switching between mail/views is difficult, knowing what calendar you're working on is difficult for people, especially with read only calendars, the tab style is also difficult for people. These things can be solved fairly simply by reorganizing the UI. We might improve part of the UI first, like the three pane concept first. Improve the mail pane integration would be a big step forward for users.

lilmatt: Given the user feedback with that mockup and since there are some of the ui bugs that we can fix now, and fix them the "right way" it will be better to get some of this stuff in now. It would be good to experiment with the UI in 0.5 and not wait until 0.7. People are already writing extensions to do some of this now anyway, so it seems like a good candidate for 0.5 in order to gain more feedback from it. More polish could of course happen later.

  • Christian will be the primary point person on that. He will come up with sketches for reorganization after determining the most crucial problems users need addressed. He will put those into the newsgroup.

lilmatt: Agenda view would also fall under the same category as the work-flow changes

  • We ran out of time
  • lilmatt will condense an updated version of this list onto the wiki and we'll discuss it in the newsgroup. Then we'll catch up with the discussion at next week's meeting.
Retrieved from "https://wiki.mozilla.org/index.php?title=Calendar:Status_Meetings:2006-10-18&oldid=38290"