[So I said I'd post these 24 hours after the meeting, once people had a
chance to look over them and make sure they were accurate. But I made
the mistake of assuming I'd remember, rather than putting it in my
calendar, so here they are 6 days later! Next time I promise to post
minutes, I'll put it in my calendar.]
Drivers meeting, 2006-03-14, 13:00-13:42 PST
Present: Chris Hofmann, David Baron, Mike Kaply, Tim Rowley, Mike Schroepfer
Scribe (i.e., minute taker): David Baron
mkaply: Should there be more regular meetings of drivers to discuss issues
rather than just emails, which sometimes doesn't go anywhere?
mkaply: That's why I asked for this meeting a few weeks ago.
chofmann: Message from brendan is that drivers does 2 things: (1)
release management (2) appeal for hard technical calls. And we do need
groups to do those two things.
schrep: Balance forum for discussions of difficult things (e.g., module
owner being unreasonable, which you may not want to discuss in public)
with need for openness. I agree there should be some project-wide
authority for these things, and I haven't seen a better proposal for
mkaply: What kind of issues are handled by drivers vs. handled by
Firefox people (Firefox product team), Thunderbird people, Gecko people.
How are the two separated?
schrep: There are still Gecko/platform issues. e.g., if Firefox team
wanted to do something that didn't fit withthe rest of the product.
chofmann: Case happening more is that we have product teams and drivers
is serving mostly as the Gecko arbitrator. And we don't have sufficient
communication between the groups, or maybe the groups need more
unification of decision making. When we had the suite drivers was
making all the decisions.
mkaply: New world, Corp. is hiring people to act as project managers.
Drivers acted as project management team and arbitrators; now there are
people paid to be project managers. And sometimes you (Corp.) guys can
go in a room and make bug decisions, and that can be more convenient.
chofmann: We should figure out what problems, if any, exist.
mkaply: Darin thought there was a problem.
chofmann: His concerns were more about the larger decisions, and whether
that was actually what drivers does, than about release management. The
only technical decisions on drivers lately have been about SVG features
for 1.8 branch (1.8.1).
mkaply: We tried to bring that in to the FF2 planning meeting, but
they're not very interested in that stuff. It seems like the platform
isn't what that group is worrying about.
chofmann: Sounds like there's neglect on drivers of discussing technical
issues that need to be resolved. Another problem to solve is how
back-end plans fit in to feature-driven release and what coordination is
needed. Two basic proposals are (1) if you're doing a release (and
forming a team like bonecho), you have to do comprehensive planning of
what backend stuff -- or decide what backend stuff is needed or (2)...
schrep: I don't want to dive into FF2-specific issues (lack of a
platform representative in those meetings).
mkaply: Easy answer: we know that. The moment you branch you lose your
platform people. The problem is long-term branch that platform people
don't want to work on.
dbaron: In this case, the goals of the branch were set explicitly that
chofmann: And maybe the goals of the branch have morphed over time.
mkaply: That's why we want short-lived branches. People stop caring
about long-lived branches.
chofmann: There hasn't been much discussion about whether these
long-lived branches are making sense.
schrep: There was a fairly long discussion about it when this plan went
mkaply: Looking at it in the world of developing products, you want
branches. But in an open-source world, people like working on the
trunk. It's hard to maintain multiple trees, land in multiple places,
schrep: We've been hoping to get people on the platform side to nominate
things that should go into the branch, i.e., cherry-pick stuff from
trunk, and that's what we said we'd do and haven't done yet.
chofmann: Who are those people, and who decides what those things are?
chofmann: So it sounds like SVG, we're at least halfway resolved on
what's going in for 1.8.1. Are there other platform pieces where there
are decisions in limbo?
mkaply: I don't know of others.
chofmann: The textPath changes are kind of approved.
mkaply: We were still hoping to convince people about filters.
mkaply: Would that discussion have been better had with drivers or with
the FF2 product team?
dbaron: I think you definitely want Gecko people involved in that
schrep: Yes, I think making the decisions without the right technical
expertise there could lead to disaster.
mkaply: But technically we made a decision without the FF2 people
involved about what SVG features would be in FF2.
schrep: Ben is on drivers; I attend both meetings.
mkaply: I'm worried that the FF team feels that drivers are forcing
stuff on them. Is there something specific that drivers own, or do they
really only own core Gecko decisions?
schrep: Who is the owner of Gecko overall? of the platform side? is
mkaply: What most people consider drivers to be is (1) approve stuff for
releases (2) oracle for when you don't know what to do. It seems like
approval stuff is now being taken over by product teams.
chofmann: We have morphed to separate of product and backend decision
making. Maybe it's just a matter of documenting that and articulating
it more clearly.
mkaply: What concerns me is company-confidential stuff. There can be
stuff on drivers that not everybody should know about. I sometimes want
to talk about IBM things that I don't want posted publicly; if we opened
up drivers then that forum would go away.
chofmann: That same aspect exists for product teams as well as drivers.
There's going to be confidential information for product releases as
well as core technology. So maybe that should be articulated.
schrep: With the FF2 list, we made bonecho public. The idea was to
create bonecho-private if there needed to be restricted discussions, but
we haven't needed to do that yet.
schrep: I'm finding it hard to have this discussion without Brendan.
schrep: I want there to be a way for people outside of Moz Corp to be
able to paricipate in releases. And I want FF team and platform team to
be able to communicate more.
mkaply: In some ways that's happened; there's really a Firefox focus
now. As a whole, the focus is Firefox.
chofmann: There are things going on that aren't specifically Firefox
focused. Cairo, Minimo, Thunderbird.
schrep: I'm wondering how we make progress. We could go through a set
of proposals for what to change / not change. Clarifying roles?
Changing things, e.g., opening lists?
chofmann: We should break it down into (1) what's actually happening and
(2) what needs to change.
mkaply: From historical view, problems have been simple things like
nobody responding to an email to drivers because everybody thinks
someone else will respond, or that when decisions need to be made,
somebody needs to set up a phone call so it can be made. As a whole,
drivers doesn't seem to be a cohesive team.
chofmann: That seems like something on the what needs to change list:
we need somebody who's running drivers, making sure questions brought to
drivers are answered and followed up on. We need to identify somebody
who's making things happen. Maybe that's just a discussion among
drivers. In the past, we've played tag with that role, but we haven't
lately. I think that mechanism has worked well in the past.
mkaply: I agree that there needs to be somebody taking ownership. But
in a way, are there too many people -- when question is asked and you
get 10 people debating the answer?
chofmann: The difference now is that nobody's driving the thing to
resolution after we get 10 opinions. If we can get back to having
someone on the hook for making sure decisions are made, that would help.
mkaply: Like EU's rotating presidency!
chofmann: It was more clear when it was mostly Asa and me, and sometimes
different people (e.g., mkaply) to drive a branch. mkaply, are you
ready to be tagged for doing some of this? We should figure out who's
the point person for drivers (maybe not the right name).
mkaply: I like the idea of having somebody rotating through who should
work to drive things to resolution. Usually, we get email, and then
another email a week later asking for a response. Or 100 emails within
a day and again no resolution.
schrep: Sometimes email isn't the best way to make decisions.
mkaply: That's why I was proposing that having regular drivers calls
would be a good idea.
schrep: And we could use those to make sure open issues get resolved.
schrep: Plus clarifying the role of drivers relationship to product
teams is a useful discussion.
mkaply: I haven't read through everything in the news group yet on
clarifying the role. I think having product team reps on drivers is
important, but I think drivers as a place to arbitrate within the
community in important, whether technical or release. How do we decide
what drivers really is so we can communicate it well to people like
chofmann: I think going back to describing what drivers have done in the
past and what we think the should be doing right now is what we need to
do. I think that's:
* arbitrating tough technical decisions, esp. for Gecko
* appeal for product team decisions
* branch planning and management
I think the harder call is about release management and who should do
that now. Product teams or drivers or hybrid?
dbaron: Or module owners, which we're sort of using for 1.8.1?
chofmann: That won't work at the endgame of releases.
dbaron: Yeah, not for the endgame.
chofmann: We've gotten along without doing endgame stuff except for the
security stuff since FF 1.5. Now that we've got more of a hybrid.
schrep: There was a deer park product team.
chofmann: But the approvals were drivers.
chofmann: We need to figure out whether that's what we'll continue to do
or whether it should morph.
mkaply: I think maybe the product teams should be more responsible, they
understand why things are important.
schrep: Seamonkey-only and Camino-only is already deferred to those
teams; similar treatment for Firefox front-end changes for Firefox?
schrep: That's why there's some separation of bugzilla flags between
Core and Firefox products.
mkaply: We're missing some people who need to be in this discussion,
esp. roc and brendan.
schrep: Write up notes from this, try to get more people at the next
chofmann: mkaply, ok, you seem to be tagged for now, first task can be
trying to get more people at the next meeting (next week?).
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
On 3/20/06, L. David Baron <[hidden email]> wrote:
> [So I said I'd post these 24 hours after the meeting, once people had a
> chance to look over them and make sure they were accurate. But I made
> the mistake of assuming I'd remember, rather than putting it in my
> calendar, so here they are 6 days later! Next time I promise to post
> minutes, I'll put it in my calendar.]
dev-planning mailing list
[hidden email] https://lists.mozilla.org/listinfo/dev-planning
> Thanks for the meeting minutes! :-)
> On 3/20/06, L. David Baron <[hidden email]> wrote:
>> [So I said I'd post these 24 hours after the meeting, once people had a
>> chance to look over them and make sure they were accurate. But I made
>> the mistake of assuming I'd remember, rather than putting it in my
>> calendar, so here they are 6 days later! Next time I promise to post
>> minutes, I'll put it in my calendar.]