Personal tools

Thunderbird/StatusMeetings/2012-09-25

From MozillaWiki

Jump to: navigation, search


« previous week | index | next week »

Thunderbird Meeting Details :

Remember to use headphones and mute yourself when not talking

Feel free to ask questions in the meeting either by speaking up or by asking them in #maildev on IRC.

Other ways to get in touch with us can be found on our communications page

Agenda

  • Who's taking minutes? --> mconley
  • Minute taking Schedule. Talk to Standard8 for schedule changes/additions.
  • Note: this meeting is for interactive discussion. Feel free to ask questions!

Action Items

Friends of the Tree

Thanks to our Friend of the Tree. When adding someone to this section, please get their T-Shirt size, phone number (needed for shipping!) and send it to abourcier@mozilla.com that she can send them a shirt!

Thunderbird Development

Feature Work

Filelink (Big Files)
  • Fixed a bug (files with parentheses in them for Ubuntu One) - see bug 793749
Instant Messaging
Modern Address Book

Google Summer of Code Projects

Mark promises to have the summary ready for next week.

App Tabs for Thunderbird
Improving GMail Integration
Get ISPDB into Production
'No reply' reminder for Thunderbird

Schedule and Progress

Beta Version
  • New beta this week.
  • Hoping to get some compacting and database fixes in.
  • This is the first release where we're testing the staging of updates in the background. Woo!
ESR

Extension of the week

  • Gecko Profiler , finding thunderbird slow ? use this extension to submit what's wrong with it and we'll probably investigate.
    • Let's monitor the download numbers on this add-on and see if it gets some traction
    • Let's enable profiling on our Daily builds. bug 794988

QA Updates

  • Working on analyzing the results of the test week.
  • 88% Test coverage last week. Thank everyone who participated. 20 bugs were filed, and we're going to analyze them shortly.

Marketing Updates

  • Nothing to report this week.

Build / Release Update

  • No major changes this week to report.

Web Update

  • Have a fix for no-earlybird-download-page issue
  • Updated Start Page
  • working on mozilla.org transition/layout stuff

Support & Documentation

  1. TB Support Community Meeting September 22, 2012 Minutes - Tentative next meeting is Saturday October 13, 5a.m. Pacific
  2. Please add any issues to the Thunderbird 15.0 Support issues page using the tagging convention from the TB15 Support Day Etherpad. Use the following tags and any other relevant Get Satisfaction tags as appropriate: tb15, tb15upgrade, tb15ubuntuone, tb15im,tb15twitter, tb15irc, tb15gtalk, tb15xmpp, tb15compactloss
  3. 1234 new support topics (1382 one week ago ) - Media:17-23September2012-GS-TB-stats-Community_stats_for_Mozilla_Messaging.png
  4. See this week's Support Appendix for full Get Satisfaction metrics and other support details

Lightning Updates

Status Updates

See the Mozilla Status Board for status updates specific to developers.

Roundtable Highlights

  • We've had various discussions going on about Governanace on tb-planning, and we're like to start bringing those to a summary and come to some decisions / conclusions.
    • There are still some open questions, but we'd like to get as many of those answers as possible in the next few weeks, because it's only a couple of months before these plans have to start being enacted.
    • If the folks who kicked off those summaries can revise their summaries, develop conclusions based on the information in the bug, and post them on a wiki, that'd be great.
    • Just so we're clear, this is regarding governance, release planning (but not necessarily from the repository level). We're talking about high-level release planning.
    • The consensus seems to be that there would be no need for an intermediate release - though jb is defending keeping the option open, if at some point it seems like it'd be an interesting release to do.
      • rent: It's extremely complicated figuring out how to do that with our current repository model. If we do it, we should do it to stabilize the product in some way - at least, that's the consensus I was getting in tb-planning.
      • jb: If there are enough contributions from now until say April of next year, it'd be nice to be able to bring those to release rather than waiting for the next cycle in September. But I understand the complexity of managing things, in particular, the extra maintenance work it'd require. So let's not close the door entirely on this. We'll see what kind of contributions come in, and if we decide to do an intermediate release, we'll do one.
    • rent: On the governance issue - if I look at the current list of module owners, it doesn't seem to map properly to who's still involved in the project. Kairo and Bienvenu are still on the list. Cranmer is on the list only for the Build config. We should modify this to reflect who the leadership is.
      • Standard8: I would look at the TB list and now the MailNews Core list of module owners. It's a small list, but it more closely reflects reality, especially wrt Thunderbird. https://wiki.mozilla.org/Modules/Thunderbird
      • There's no business module, but that's kind of by design (module owners is for technical matters - though we did at one time discuss putting in non-technical modules).
      • bwinton to rent: Please propose any changes for the module owners list that you think could bring it more up to date.
      • Standard8: From the perspective on non-technical items, we could reasonably / easily define those (at least, separately for now - maybe on the new governance page). There is scope for doing non-technical modules, but we'd need to look at the background of those a bit more.
      • jb: Module owners are responsive for maintaining their modules in good health. It doesn't mean that they are necessarily leaders, that they have extra powers to drive the direction of so and such and such modules - but their responsibility is to make sure that the code works properly and integrates properly. Module owners do not necessarily imply Thunderbird leaders. We're free to set up an extra function in governance for project management. The governance we're proposing is very light-weight: Module owners to keep the code in good health. Drivers to release the product. If natural leadership emerges that is able to foster attention and drive projects forward, that'd be awesome. Module owners != leaders necessarily.
      • rent: The primary governance is going to be module owners…but you've just said that it's a purposely weak leadership. Is that right?
      • jb: correct.
      • Irving: I think Mozilla is just not putting a leader in place to make management decisions.
      • bwinton: if the community wants project leadership (and I think they do), they'll have to step up. I think we should have a business development person in that community who can arrange meetings with partners, etc.
      • jb: Mozilla is providing support, wrt legal, business arrangements. The question is - who has the authority to negotiate deals with such and such partners? We don't have the answer to that just yet.
      • bwinton: I don't have any modules, but we have ui-review for things touching UI need…so UI isn't exactly a module, but there seems to be an extra layer on top of just the module owners that isn't described anywhere. We should probably make that more clear somewhere.
      • rent: We need a document to list the actual leadership of the project. And you keep saying that the community needs to do this, but you haven't supplied a mechanism for doing that.
      • bwinton: I think the mechanism is that someone posts to tb-planning, saying "this is how things should be", and then we discuss it. Posting to tb-planning is usually the best first step.
      • jb: Let's take rkent as an example of someone who's stepped up to be a leader, because he's driving things, he's asking questions, playing the role of a leader. Module ownership doesn't make much of a difference there. You're fingerprinting and asking questions, and driving us to make progress. This is good. I like this light-weight approach.
      • andreasn: A bit like herding cats.
      • rent: I'm not at the moment ready to accept any position of leadership at this point yet. I think that's enough on this topic for now.
  • rkent: I think we need to empower people in QA and support. Wayne and QA have started creating these lists. How do we move forward on fixing those bugs?
    • Irving: I think visibility is part of it. Having everybody know where the list is is a start. Linking to it from the weekly meeting would help.
    • Standard8: It's a difficult thing to do lists. The problem is getting people interested and fixing things on the list.
    • Irving: Awareness of the list, and the cultural shift of buying into the list - a shared place for us to agree on what's important to work on next. Visibility is important. Maybe a reminder that it exists each meeting.
    • roland: Wayne and I have been making lists forever. The only bug that really really needs to be fixed is the compacting bugs, which somebody is fixing (rkent!).
    • Standard8: We're pretty good at tracking / fixing the high-frequency support bugs.
    • Wayne: it's the level between paper cuts and must-fixes that we have to look at
    • Irving: a lot of performance stuff slipped - some stuff slipped into Aurora / Beta that really killed performance that one time.
    • roland: The fact that we don't have enough beta exposure is a pretty big problem… :/
    • Irving: catching the grumblings and triaging / prioritizing them is important. The grumblings didn't feel serious at first…and then suddenly they were really bad.
    • rent: I would encourage you to think of this in this way: it's just as important that the community feel empowered, that their work has meaning, *along* with the bugs being fixed. We have to respond to their requests.
    • Standard8: Again, it's visibility. We need to see this list all the time.
    • Wayne: I'm on board with a bunch of these ideas. Our high-level wiki is somewhat out of date, and I would be willing to take a look at it and work with anybody to bring some more coherence to our wiki.
  • Irving: no luck with the Mac top-crasher in 15.0.1…
    • Standard8: I've got someone who can supposedly reproduce it very easily, and I'm working with them to try to narrow it down to see if there's a specific build that regresses it or not. If anybody is able to reproduce this crash easily / reliably, get in touch with me!

Attendees