Thunderbird/StatusMeetings/2012-09-25: Difference between revisions

← Older edit

Thunderbird/StatusMeetings/2012-09-25 (view source)

Revision as of 16:25, 27 September 2012

7,949 bytes added , 27 September 2012

→‎Roundtable Highlights

Mconley

Confirmed users, Bureaucrats and Sysops emeriti

998

edits

@@ Line 80: / Line 80: @@
 * 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 =====
@@ Line 85: / Line 87: @@
 === Extension of the week ===
 * [https://addons.mozilla.org/en-US/thunderbird/addon/gecko-profiler/ 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}}
 === [[Thunderbird:Testing|QA]] Updates ===
 * Working on analyzing the results of the test week.
-* 88% Test coverage last week. Thank everyone who participated.
+* 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 ===
@@ Line 114: / Line 120: @@
 === 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 [https://wiki.mozilla.org/Thunderbird 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 ===
 __NOTOC__