2006-02-27 - Summary of mozilla.org staff meeting
Gervase Markham
-------------------------------------------------
Present: aravind, autonome, bc, beltzner, bienvenu, brendan, bsmedberg,
chofmann, coop, davel, dria, dveditz, enn, graydon, jay, Jesse, josh,
jst, justdave, justdave, justin, karen, marcia, mconnor, mitchell,
mrbkap, mscott, myk, pike, polvi, preed, rebron, rob_strong, sicking,
stuartp, timr, vlad
*Around the World, Around the World*
- jlilly and schrep are in Japan for a Mozilla Japan event
- http://www.mozilla-japan.org/events/200603/seminar
- The Mozilla Japan staff are planning to come to MozHQ soon, perhaps
for the quarterly all hands meeting
- cbeard and pkim are at FOSDEM and talking with ad agencies in London
*Firefox 1.0.8*
- keep finding critical security bugs before release
- hoping to get them in today and get the builds started (about 3 days
later than last scheduled date)
*Firefox 1.5.0.2*
- http://wiki.mozilla.org/Firefox:1.5.0.2:Schedule
- hope to have it wrapped by Friday, about 16 bugs left to land
- turns out this works well since the team is busy testing 1.0.8
- still aiming for published release date
- QA is going to feel the crunch as testing requirements for Firefox 2
increase
* Suite 1.7.x *
- shaver and beard will come up with a crisp message about the
support/maintenance path for Suite/Seamonkey
* Firefox 2 *
- http://wiki.mozilla.org/Firefox2
- need to finish product requirements document, based on that we can
come up with a better schedule that has more realistic dates (still
aiming at 3Q2006)
- discussion on wiki.mozilla.org/Firefox2 and
dev-apps...@lists.mozilla.org
- mitchell: so we need to get that first document in place and then get
a much more global understanding of what Firefox 2 is, and when it's
coming, because it's coming up quick
- sicking: when we do platform fixes, we're landing on trunk and the 1.8
branch almost automatically, is that slowing us down?
- shaver: I think that the things we're taking there are known-wanted
compatibility fixes. Anything we put in 1.8 should come through the
trunk. Haven't seen anyone complaining yet. So far it's been pretty
conservative stuff (crash fixes, etc) and we should be trying to
take them earlier than later, but if this starts to be a problem we
should back those things out to minimize churn.
- mconnor: as long as we're maintaining API compatibility, it
shouldn't slow us down at all
*Trunk/Firefox 3*
- cairo has been turned on by default on windows trunk builds
- we've also started to move to VC8
- there's been some pain points, but things are working pretty well
- preed: need to figure out what the tinderbox build farm needs to look
like in terms of compilers
- mscott: want to point out that stuart and vlad did an excellent job in
assisting with that transition
- things are looking good for making the move to cairo on all platforms
- sicking: when places landed on trunk/branch, Tp went up by 100% ; we
should avoid that sort of thing happening again.
- brendan: regression tests should be run locally before patches of
that size are dropped on the trunk
- sicking: we need some sort of rules about what size of regressions
will cause automatic backout
- brendan: those are the rules for sheriffing, and if we need to be
more aggressive there, we need to talk about it. currently sheriff
is #developers, but maybe that's too distributed
- shaver and brendan to take this issue to drivers@
*Other Engineering*
- bsmedberg: if you notice interesting linux distribution packaging
issues with Firefox, or XULRunner, please let me know, I'm trying to
build a list
- shaver: just so you know, we've been trying to go top-down to
address this with the major linux distributors
- mitchell: it's a big discussion, and there are lots of issues to be
explored; shaver and jlilly have been digging into this, but go,
benjamin!
*Marketing*
- Extend Firefox contest winners will be announced this week
*Foundation*
- FOSDEM went well, look for Gerv's blog post soon
- Foundation is sponsoring a booth at the CSUN Conference on Technology
for People with Disabilities
- Frank will be in California next week for the Mozilla Foundation Board
meeting
- Progress is being made on the Mozilla Code Relicensing
- Chris Blizzard's recent trip to India was interesting, and shows that
there's some opportunity there if we can find the actors to make it
happen
- mitchell is still looking at the history of "choice and innovation" as
the Mozilla Mission Statement, and hopes to get something published
about that soon
Mike (Beltzner)
Darin Fisher
meetings or mozilla.com staff meetings? They seem to have morphed
into the latter. Is there a reason why these meetings are not open to
the entire mozilla development community?
-Darin
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Darin Fisher
> should avoid that sort of thing happening again.
> - brendan: regression tests should be run locally before patches of
> that size are dropped on the trunk
> - sicking: we need some sort of rules about what size of regressions
> will cause automatic backout
> - brendan: those are the rules for sheriffing, and if we need to be
> more aggressive there, we need to talk about it. currently sheriff
> is #developers, but maybe that's too distributed
Guys, the decision was made to enable places on the trunk at the FF2
planning meeting. We knew it would have issues, but we felt that it
was worth it to get it enabled to help expedite the feature. As I
recall, everyone at that meeting was in agreement with this plan.
Yes, not everyone was at the meeting, and that makes it hard to make
exceptional decisions such as the one that was made, so perhaps
communication could have been better?
When the performance problems hit, Brett and others scrambled to fix
the problems. Eventually, the feature was reverted to being disabled
by default. Improvements were made, and then the feature was
re-enabled. Each time it was enabled, we learned several very
valuable things. For example, we learned about difficult-to-reproduce
data loss bugs, and those bugs have been getting fixed. Having this
feature enabled in some nightly builds was invaluable. I think it
would have been a huge mistake to disable places after that first
round of bad numbers from our performance regression tests.
That said, I agree that it is good to run as many regression tests as
is feasible prior to checkin. We now have a dedicated Tp server at
our office, and Brett is in the process of setting up a dedicated Tp
client machine so we can more accurately test changes that may impact
Tp. I think that's a step in the right direction.
> shaver and brendan to take this issue to drivers@
Huh? Why discuss this on the private drivers mailing list? What will
that solve? Why not discuss this in the open with the development
community? (I sent mail before to drivers asking why it had to be a
closed mailing list, and I was given "good" reasons. Stuff like this,
however, makes me quite dismayed.)
-Darin
Ben Goodger
>> shaver and brendan to take this issue to drivers@
>
> Huh? Why discuss this on the private drivers mailing list? What will
> that solve? Why not discuss this in the open with the development
> community? (I sent mail before to drivers asking why it had to be a
> closed mailing list, and I was given "good" reasons. Stuff like this,
> however, makes me quite dismayed.)
The Mozilla project, even within the context of a single project
(Firefox) has too many distinct, mysteriously populated groups. This is
a source of great confusion to many contributors.
In my opinion, we need to focus on using /these/ (lists.mozilla.org)
/public/ discussion lists for all project related communications where
people are seeking consensus or resolution.
I asked yesterday in IRC where the canonical place for development
discussion was and the answer shaver gave me was "here" (#developers). I
don't think that's good enough for the long term viability of the
project. People need to see how and why decisions were made.
This was a problem with Firefox development and part of the reason why I
evangelized folk to use the dev-apps-firefox group so strongly.
I don't want to just complain though. I want to help. Is anyone else
interested in tackling this?
-Ben
Mike Beltzner
> In my opinion, we need to focus on using /these/ (lists.mozilla.org)
> /public/ discussion lists for all project related communications where
> people are seeking consensus or resolution.
As I understood things, /those/ (lists.mozilla.org) discussion lists
are meant to be more stable in terms of heirarchy and existence (ie:
there will always be a dev.planning, there will always be a
dev.apps.firefox) whereas /these/ (mail.mozilla.org) lists are meant
to be fluid and based on subprojects. Thus, discussion about
development of Firefox goes in dev.apps.firefox, but discussion about
the Bon Echo project management goes to bon...@mozilla.org, since the
Bon Echo project will end in a relatively short time, but Firefox
development will go on forever.
Perhaps we should close bonecho@ and move that discussion into
dev.planning, though. I'd be fine with that. Should we do that with
all the lists at mozilla.org?
> I don't want to just complain though. I want to help. Is anyone else
> interested in tackling this?
Very. My ENTJ brain yearns for structure and easing entry and
understanding of where people go to participate/research certain
decisions. If one asked me, I would propose that the best way to do
this would be:
- a wiki page is used as the "home" for each project, release & feature
- projects point to 1..n releases, releases point to 1..n features
- features can exist that aren't targeted to a specific release
- the wiki page holds documentation, plans, decisions, meeting notes, etc
- the wiki pages link to the appropriate discussion forums for that thing
That way the more permanent things have a home on the web (with
completely visible revision history, etc) and pointers to the more
transient discussion forums. Whereever possible, the wiki records of
decision points should link to the discussion forum threads (thanks,
Google Groups)
</rambling>
cheers,
mike
--
-------
mike beltzner, user experience lead, mozilla corporation
Gervase Markham
> Perhaps we should close bonecho@ and move that discussion into
> dev.planning, though. I'd be fine with that. Should we do that with
> all the lists at mozilla.org?
I haven't looked at the list of lists, but it seems to me to make sense
to try and have as much discussion as possible in long-lived (and
therefore more complete and easily-searchable) groups.
Gerv
Gervase Markham
> I've been meaning to ask... are these meetings mozilla.org staff
> meetings or mozilla.com staff meetings? They seem to have morphed
> into the latter.
They were mozilla.org staff meetings. Then they sort of became
Foundation meetings. When the Corporation was founded, they became sort
of sequential staff and Corporation meetings.
staff used to discuss more confidential items than is now the case; a
lot of the business development stuff, for example, is now with the
Corporation.
This ties into the as-yet-unsettled question of the role of mozilla.org
staff in the new world.
> Is there a reason why these meetings are not open to
> the entire mozilla development community?
It's certainly arguable that the type of meeting they now are should be
open to more people.
Gerv
Gervase Markham
> I asked yesterday in IRC where the canonical place for development
> discussion was and the answer shaver gave me was "here" (#developers). I
> don't think that's good enough for the long term viability of the
> project. People need to see how and why decisions were made.
Sure. Although we should probably also have a web-accessible log of the
IRC channel.
> This was a problem with Firefox development and part of the reason why I
> evangelized folk to use the dev-apps-firefox group so strongly.
And I think it's made a really big difference. Thank you for doing that.
Gerv
Mike Pinkerton
"I don't want to just complain though. I want to help. Is anyone else
interested in tackling this?"
-Pink
Ben Goodger
I agree. When bugs or specific issues are discussed in a project
management meeting/list and the effect hits a bug (being minused, or
some other such change), people often wonder what happened or why.
Should we start a communication grouplet (group of folk) whose focus is
ensuring these issues get fixed? I think this is one of the reasons this
longstanding problem has never been fully addressed. I know you've been
doing a lot of hard work Gerv, but imagine you'd appreciate some help :-)
-Ben
Darin Fisher
> On 3/8/06, Ben Goodger <bengo...@gmail.com> wrote:
> > /public/ discussion lists for all project related communications where
> > people are seeking consensus or resolution.
>
> are meant to be more stable in terms of heirarchy and existence (ie:
> there will always be a dev.planning, there will always be a
> dev.apps.firefox) whereas /these/ (mail.mozilla.org) lists are meant
> to be fluid and based on subprojects. Thus, discussion about
> development of Firefox goes in dev.apps.firefox, but discussion about
> the Bon Echo project management goes to bon...@mozilla.org, since the
> Bon Echo project will end in a relatively short time, but Firefox
> development will go on forever.
>
> dev.planning, though. I'd be fine with that. Should we do that with
> all the lists at mozilla.org?
You mean all the lists at mail.mozilla.org? Yes, I think so. I'd imagine
that people have a hard time finding all the various mailing lists and
discussion forums involved with this project. I definitely think that
bonecho@ should go away. I suspect that very few people even
know about it. We should simplify. list.mozilla.org all the way :-)
-Darin
Robert Kaiser
> On 3/8/06, Mike Beltzner <mbel...@gmail.com> wrote:
>> Perhaps we should close bonecho@ and move that discussion into
>> dev.planning, though. I'd be fine with that. Should we do that with
>> all the lists at mozilla.org?
>
> You mean all the lists at mail.mozilla.org? Yes, I think so.
I actually think the mail.mozilla.org lists should stay where they are a
contact address for a very specific group of people, and should only be
used as an information channel to contact those groups, or to
communicate internal stuff that is _not_ meant to be public. This
applies to e.g mlp-staff@m.o, seamonkey-council@m.o, I guess also
staff@m.o and drivers@m.o ;-)
But everything that is of community interest and should be made public,
esp. discussions about development decisions, etc. should really go to
[lists|news].mozilla.org so that a wider community can read what's going
on, can take part, and it's permanently available.
In many cases, it might be a good idea to have a wiki document that
reflects the outcome of discussions (i.e. drafts/documents planned or
done work), it should probably get drafted with a proposal and changed
according to the lists/news discussion.
Fast ad-hoc communcation, development help and fun talk probably still
have a good reason to happen on IRC, but if development decisions are
made there, those should be reflected where appropriate (wiki,
lists/news and/or relevant bug reports), avoid to completely hide those
from the community. The same is true for stuff coming out of the
remaining mail.m.o lists.
I think this way, we could leverage the tools and infrastructure we have
while also holding up community communication, which should be an
important topic in an open source project...
Perhaps it would additionally be a good thing to have someone write up a
weekly report of happening in the mozilla.org community, like Kernel
Traffic or Wine Weekly News do, but I guess it would not only be hard to
summarize the plethora of things happening around here, but also to find
someone who'd write up that report...
Actually, the staff meeting minutes are the nearest thing to such a
report that we have - and they cover only staff meetings, not a broader
range of dicussions like the others do...
Robert Kaiser
Darin Fisher
OK, I'm glad to hear that you agree. How do we make this change happen?
-Darin
Ben Goodger
> OK, I'm glad to hear that you agree. How do we make this change happen?
Thinking on a global scale, I think we need to identify all of the
closed discussion groups that could be public, refactoring where
necessary and then discuss this with the owners of each venue. Feel free
to tell me to buzz off if you want to focus on staff first.
Oh and, is this the right list to be discussing this sort of thing?
-Ben
Mike Beltzner
Almost surely not, since I'm pretty sure that the principals of the
Mozilla Corporation -- who do indeed use these meetings to discuss
confidential Mozilla Corporation -- aren't reading this list.
Right now the meetings seem to serve two purposes:
1. Act as an all-hands weekly update for employees of MoCo
2. Discuss the status of the primary MoCo/MoFo projects
I think what you really want/mean to suggest is that the second part
be separated out and placed in some sort of public forum. Or maybe you
mean both parts ... you tell me! :)
Ben Goodger
> I think what you really want/mean to suggest is that the second part
> be separated out and placed in some sort of public forum. Or maybe you
> mean both parts ... you tell me! :)
I'm thinking about all such project lists. A few come to mind aside from
bonecho... Darin's original point was that the non-confidential(*)
discussions that take place on drivers should be open.
What else? mozilla2.0, marketing-private etc. A lot of dead lists too.
(* things not relating to requests from companies relating to sensitive
product info etc communicated to mozilla for consideration in
prioritization)
-Ben
Mike Beltzner
> bonecho... Darin's original point was that the non-confidential(*)
> discussions that take place on drivers should be open.
Yes, but we got onto meetings didn't we? Or did I totally misread?
> What else? mozilla2.0, marketing-private etc. A lot of dead lists too.
I know that marketing-private is being used quite a bit, and should
remain private, as it includes things like confidential press
announcements that can't be released due to contractual obligations,
etc. Those things are going to happen, so there will still need to be
some private lists, just like there are some private bugs. Brendan's
running mozilla2.0, but from the content that's going by in that list,
there's nothing that couldn't be done in the public.
> (* things not relating to requests from companies relating to sensitive
> product info etc communicated to mozilla for consideration in
> prioritization)
Ah, yes, you're already on this point :)
Scott MacGregor
I'm interested in helping to solve this transparency problem as well!
Simplifying and reducing the number of closed lists is one way and
there's already discussion in this thread on that front. Solving this
problem also requires a lot of self discipline whenever we submit
something. Who am I sending this to? Is that list public? Is there a
reason why my post shouldn't go to an open list? I find it's very easy
to fall into this trap if I'm not consciously thinking about it when
posting to say drivers, something which could just as easily go to the
planning newsgroup. It's an easy habit to slip into.
With regards to Darin's comments specifically about drivers, I agree
that a lot of the drivers conversations could (and should) be more
public. There will still be a need for a private list for drivers. For
instance, during the release cycle for security releases, we'll
frequently discuss and talk about respins for unannounced, confidential
security bugs and other more release driver centric issues that can't be
made public.
Maybe we need more watchdogs on drivers to help keep us honest. But that
would just help one specific case and not the other private or
semi-private mailing lists we use.
-Scott
Axel Hecht
I would like to add that the corporation-only does contain sensitive
information. Another thing is that the mofo-moco common part doesn't
have that many discussions, but is mostly reporting (which is OK given
that 40 people participate).
Maybe the term "mozilla.org staff meeting" doesn't really cut it anymore
for these meetings. I take it that the original purpose of that meeting
was taken over by the steering committee meetings?
One way to make the staff meetings more open could be to reuse the
scheme that beltzner uses for running the bonecho meetings, writing the
agenda on the wiki, getting the line item holders to fill in and then go
over that during the meeting.
As there needs to be one meeting including possibly confidential stuff,
I'd rather not open up "staff meeting" to a wider audience itself, as
that seems like it would just create yet another meeting with little
additional value. Or lead to more opaqueness inside the corporation again.
Axel
Ben Goodger
> I know that marketing-private is being used quite a bit, and should
> remain private, as it includes things like confidential press
> announcements that can't be released due to contractual obligations,
> etc. Those things are going to happen, so there will still need to be
> some private lists, just like there are some private bugs. Brendan's
> running mozilla2.0, but from the content that's going by in that list,
> there's nothing that couldn't be done in the public.
OK. Rather than continue here with incomplete data and midway through a
thread that started about something else, I'd like to adjourn this
somewhere else. I'm going to start another thread on mozilla.dev.general
for lack of a more specific place.
-
Ben
Darin Fisher
> Darin Fisher wrote:
> > I've been meaning to ask... are these meetings mozilla.org staff
> > meetings or mozilla.com staff meetings? They seem to have morphed
> > into the latter. Is there a reason why these meetings are not open to
> > the entire mozilla development community?
>
> meetings. Nor have drivers. I mean "open" in that anyone can call in
> or walk in. No healthy project works that way. All involve a broad and
> mostly [*] transparent reputation system, a meritocracy with a "natural
> elite" if you will.
Sure, my last question was asked somewhat sarcastically to emphasize
my point that it seems like the staff at mozilla.org meetings aren't
just for staff anymore! :-/
> Two things have happened -- have been allowed to happen, for fear of
> making riskier changes -- that need to be corrected:
>
> * The st...@mozilla.org meetings have been combined with paid staff of
> first MF and now MF + MC. This was calculated to do the least harm, but
> I think that may have been a mis-calculation.
>
> * The natural hacker elite rules over modules via ownership and peering,
> via super-reviewers when that still applies, and -- when people step up
> and offer to help -- through dri...@mozilla.org.
It's not clear to me what part of this second thing you feel needs to
be corrected. The natural hacker elite should most certainly rule
over modules via ownership and peering.
I'm dubious of the ongoing necessity of super-reviewers and drivers.
Is that what you were referring to?
> Drivers in particular has been less functional over time, as new apps
> such as Firefox have grown up. I've said repeatedly we can fix this
> (whatever the name, we need project management), and I've invited people
> such as bz to join. Most recently Ben joined.
>
> Yet now we have more detailed project, or really "product", management
> going on in the Firefox area, on dev-f...@l.m.o and bonecho. We have
> people at MC, Google, IBM, and other companies invested in what goes
> into Firefox or Gecko -- a decision space that for Gecko at least,
> dri...@mozilla.org still owns.
Wait, I thought the Gecko sub-module owners were responsible for what
goes into Gecko. It begs the question: "Who are these drivers anyways
and what gives them the right to trump what the engineers working on
Gecko think is best for Gecko?" Where is the meritocracy in that?
Now, I know that there is great overlap between the folks on drivers
and the Gecko module owners, so yes... in many cases, it doesn't
really matter. However, from the outside, it looks like drivers is
this mysterious entity that somehow knows best.
The only time drivers has ever had any power is during release crunch
time because someone needs to gate changes to a product in the final
hours or else we'd never ship anything decent. We need that kind of
release driving. However, it seems to me that the team leading
Firefox or Thunderbird should be responsible for those kinds of
decisions, not drivers.
I'm of the opinion that drivers should be abolished. Whatever
functions it still serves would be better performed by, for example,
the bonecho team when it comes to issues concerning the release of
Firefox 2.0 with appropriate deference and delegation to the owners of
the respective Mozilla modules.
We are using module owner approval to gate check-ins to the
MOZILLA_1_8_BRANCH. That seems to be working well so far. When it
comes time to lock-down for the FF 2 betas and release candidates, we
should select a group of people (perhaps a subset of the bonecho team)
to be responsible for that effort. They should work closely with the
module owners to review patch approval requests. Most of this can and
should be done in the open (perhaps on the bonecho mailing list or
whatever supercedes it). It'd seem ideal to me if patch approval
requests for FF 2 could be echo'd to that mailing list.
> It's clear that we need greater clarity about where responsibility with
> natural authority by meritocratic acclamation (we don't want other kinds
> of authority; we don't want responsibility without authority) lies for
> the many moving pieces.
>
> I agree we should get rid of closed lists, except where they function
> for business-confidential reasons. I'm sure the Google folks would
> agree, since they have their own such lists.
Yes, I like Ben's suggestion of choosing names for those closed
mailing lists that clearly indicate their purpose and function.
Everybody can understand the importance of a security mailing list
where discussions happen regarding as-yet-undisclosed security
vulnerabilities. The same goes for certain marketing discussions,
where sensitive deal-making is involved.
> BTW, mozil...@mozilla.org now has a publicly accessible archive.
> Sorry, I thought I fixed that in January. Subscription to it is still
> moderated.
Great. I'm glad to hear that the list is now open, even if just
readonly. But, how can someone learn about such a list? Discovery is
another huge problem that we need to tackle. As Ben also said, we
need to make it really easy for someone to learn in 10 minutes how to
get around in our community.
-Darin
Brendan Eich
trimming the cc's to the list gateways. /be]
Darin Fisher wrote:
>> * The natural hacker elite rules over modules via ownership and peering,
>> via super-reviewers when that still applies, and -- when people step up
>> and offer to help -- through dri...@mozilla.org.
>
> It's not clear to me what part of this second thing you feel needs to
> be corrected. The natural hacker elite should most certainly rule
> over modules via ownership and peering.
>
> I'm dubious of the ongoing necessity of super-reviewers and drivers.
> Is that what you were referring to?
Yup.
>> Yet now we have more detailed project, or really "product", management
>> going on in the Firefox area, on dev-f...@l.m.o and bonecho. We have
>> people at MC, Google, IBM, and other companies invested in what goes
>> into Firefox or Gecko -- a decision space that for Gecko at least,
>> dri...@mozilla.org still owns.
>
> Wait, I thought the Gecko sub-module owners were responsible for what
> goes into Gecko.
That's nice. Welcome to Fat Gecko, with MNG, XForms, SVG 1.2, etc. etc.
Drivers have had to force the issue of what the Gecko "rv:" number means
in the user-agent string, where various apps wanted to pick and choose
(e.g., Camino not shipping SVG, or whether MathML needs to be there).
This is not an issue that individual modules owners necessarily solve by
themselves (ok, well, MNG was solved by strong-owner pav, but drivers
had to adjudicate when MNG fans protested -- if you eliminate drivers,
this will just bubble up to the next layer of buck-stopping, staff --
and quickly from there to me, and I'll want to consult with drivers).
This is not the only such issue.
> It begs the question: "Who are these drivers anyways
> and what gives them the right to trump what the engineers working on
> Gecko think is best for Gecko?" Where is the meritocracy in that?
The drivers group were skimmed off the top of the meritocracy by me,
long ago, and self-appointed or accepted volunteers who came from the
same layer of cream in order to perpetuate itself.
You aren't knocking roc, here, I hope :-P.
Seriously, some drivers are pretty uninvolved. The group is neither as
active nor as crucial as it once was, which again was my point. But
your "let module owners decide" point is either not serious, or is
simplistic. No self-organizing module owner system will always or even
often spontaneously order the whole in the best way for all the parts --
especially when there are multiple "wholes" (multiple Gecko branches and
rv: values, multiple XUL and Gecko based apps).
I'm focusing more on "what is Gecko, what does that rv: mean?" here.
Drivers also have to order the milestones and branching plan, although
that often falls to a handful, including me. Again, it ain't perfect,
but it also isn't covered by module owners doing their thing.
> Now, I know that there is great overlap between the folks on drivers
> and the Gecko module owners, so yes... in many cases, it doesn't
> really matter.
Not my point, and not true when there is conflict. We have dbaron, roc,
bz now in drivers, but we also have non-Gecko-owning drivers, and
hackers or even module owners in "Gecko" (writ large) who are not
driverly -- who do not look at the big picture so much as you would want
in order to have a well-defined Gecko rv:, a usable milestone plan, or
other global kinds of non-modules that are not delivered by module owners.
We have lots of people adding value in various ways, but both global
big-picture planning and mundane release management grunt work often get
neglected. Drivers was charged with both these lofty and dirty aspects
of project management in the original roadmap
(http://www.mozilla.org/roadmap/roadmap-26-Oct-1998.html).
> However, from the outside, it looks like drivers is
> this mysterious entity that somehow knows best.
No one knows best all the time, not even the best module owners.
Someone has to call certain milestone-scheduling and what-is-Gecko
shots. Same for what-is-in-Firefox. That's not done bottom-up by
dozens of module owners. There is no single "Gecko" module that one
person owns (with peers). There is no single "Firefox the whole app"
module, although the Browser is much closer to that ideal than any
analogous Gecko module.
We've had good leadership for Firefox, in my opinion, but the Gecko
1.7.5 rv: and many other contributions from non-front-end modules
required some drivers help. Lots of stuff between front and back ends,
and involving other projects including the suite, fell through cracks in
the aviary branch. The whole "new roadmap" of April 2003 that moved the
project away from the suite required driver effort, not just module
owner effort.
And project management duties involve more than milestone scheduling.
Tree freezing well before release crunch, judging risk of a change that
cuts across modules, etc. all have involved drivers as well as module
owners.
Now you may say that looking out for cross-module dependencies can be
done by anyone (super-reviewers are charged to oversee it), and you're
right. No one necessarily "knows best", but having a group (called
drivers, the name's not important but the role is) that is charged with
responsibility for this kind of work tends to focus certain minds to
better effect than doing without. Sure, we should all focus on all
these things all the time. Obviously, we can't and don't.
Lots of open source projects have something like drivers. I'm thinking
of FreeBSD and Apache in particular. Formalizing governance structure
could help to reform drivers; I'm in favor and I've talked to Frank
Hecker about this a bit. But just saying "we don't need no steenking
drivers!" and relying on module owners won't suffice.
> The only time drivers has ever had any power is during release crunch
> time because someone needs to gate changes to a product in the final
> hours or else we'd never ship anything decent.
Not true, see MNG and other such things in the past, and more recent
decision-making over SVG. Also the alpha-stage landings, what should go
into early-stage trunks (e.g. 1.9), have involved drivers.
> We need that kind of
> release driving. However, it seems to me that the team leading
> Firefox or Thunderbird should be responsible for those kinds of
> decisions, not drivers.
Firefox team leads will pick and choose which modules make up Gecko as
identified in the user-agent? No.
Gecko owners will pick and choose? Maybe, but Firefox leads may need to
give feedback. This happens all the time without drivers, but there has
been and will be conflict, and drivers provide mediation. Someone has
to mediate, and not just using Eliza-ish non-directive therapy and
fence-sitting, but with leadership qualities.
While I am ultimate buck-stopper, but it makes no sense to cut out a
subsidiary layer such as drivers. If we need to reform drivers, let's
do that. But don't throw baby out with bath-water.
> I'm of the opinion that drivers should be abolished. Whatever
> functions it still serves would be better performed by, for example,
> the bonecho team when it comes to issues concerning the release of
> Firefox 2.0 with appropriate deference and delegation to the owners of
> the respective Mozilla modules.
You want to rename drivers to bonecho. Tell me what's changed other
than the name. The people? Are you proposing that front-end focused
contributors alone decide what rv: 1.8.1 means? Again I object.
There's a role for global project management, and global means back- as
well as front-end. We often don't know enough about subtle or even
unknown (latent) bugs that will frustrate FE-only feature pushes. This
happened late in 1.5 with tabbed browsing, and ended with hard feelings.
I'm going to delve into it at the risk of opening wounds.
If the FE people were truly in charge, then there should have been no
problem pinned on lack of BE bugfixing, no finger-pointing (because with
authority comes responsibility). And, if there was a lack of BE
bugfixing for the tabbed browsing (window targeting, really) fixes, then
apart from lack of planning that spans modules, it probably had a lot to
do with bfcache's opportunity costs, because both bfcache and window
targeting required bz.
I'm not knocking bfcache here. I'm specifically citing this as evidence
of something missing at the module owner or Firefox product team level,
in our recent experience, that could be *and was* addressed in part by
drivers. Drivers were actively involved in bfcache landing and turn-on.
Nothing was perfect here, but there was a role for drivers, and your
proposal to cut it out leaves me cold.
> We are using module owner approval to gate check-ins to the
> MOZILLA_1_8_BRANCH. That seems to be working well so far.
C'mon, we rely on module owners alone, no mandatory or advisory access
controls, almost always on the trunk. That's not the hard case, so no
points awarded from me.
> When it
> comes time to lock-down for the FF 2 betas and release candidates, we
> should select a group of people (perhaps a subset of the bonecho team)
> to be responsible for that effort.
Hey, sounds like drivers.
Again, I'm the one saying drivers needs updating, and that I don't care
about the name (but why change it gratuitously). So if we agree on the
needed reforms, why reinvent this wheel?
> They should work closely with the
> module owners to review patch approval requests.
Drivers do this and have historically done this. Same wheel.
> Most of this can and
> should be done in the open (perhaps on the bonecho mailing list or
> whatever supercedes it). It'd seem ideal to me if patch approval
> requests for FF 2 could be echo'd to that mailing list.
You don't want bugzilla-request-daemon mail spamming bonecho. You do
not want all bugs discussed in the open by everyone. I'm not just
talking about security bugs (mail to security-group and drivers
overlaps, and bugzilla-sent mail about security-sensitive bugs goes to
dri...@mozilla.org). I am also talking about hard cases and hard
feelings, human management issues.
Nevertheless, with the right bugmail routing, and a private list for
hard cases, we could open up drivers, for sure. If we did, perhaps you
would see more value in it.
Perhaps not: drivers is not exactly super-active, and much of the
activity is pure grunt work about the patch releases (with a bunch of
security-sensitive stuff, so again not going into an open list). Some
of this is summarized on wikis anyway, but I dislike using wikis for
threaded discussions.
>> BTW, mozil...@mozilla.org now has a publicly accessible archive.
>> Sorry, I thought I fixed that in January. Subscription to it is still
>> moderated.
>
> Great. I'm glad to hear that the list is now open, even if just
> readonly. But, how can someone learn about such a list?
We used to have a community page that linked to all lists, with
descriptions. Gerv?
> Discovery is
> another huge problem that we need to tackle. As Ben also said, we
> need to make it really easy for someone to learn in 10 minutes how to
> get around in our community.
That's a great goal. In the old days, our www.mozilla.org docs tried to
make it easy, maybe not 10-minutes-easy, but easy enough. Those docs
have rusted. But we have wikis now... ;-)
/be
Gervase Markham
> Should we start a communication grouplet (group of folk) whose focus is
> ensuring these issues get fixed? I think this is one of the reasons this
> longstanding problem has never been fully addressed. I know you've been
> doing a lot of hard work Gerv, but imagine you'd appreciate some help :-)
I'd be happy to be involved in such a thing.
Gerv