Re: 2006-02-27 - Summary of mozilla.org staff meeting
Brendan Eich
> 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?
I'm a founding member of st...@mozilla.org. We have never had open
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.
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.
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.
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.
BTW, mozil...@mozilla.org now has a publicly accessible archive.
Sorry, I thought I fixed that in January. Subscription to it is still
moderated.
/be
[*] Mozilla has always appointed build and release engineers quickly,
whether hired from the community or not. This goes back to the days
when Netscape was the hiring company. Also, we have many people in our
securit...@mozilla.org who are in similar positions at downstream
distributor companies.
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?
>
> I'm a founding member of st...@mozilla.org. We have never had open
> 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
Ben Goodger
Some of the things drivers does:
- pan-gecko leadership
- confidential contact channel for corporate requirements
- end game release management
- 'high council' for some project policy issues.
I don't think anyone is suggesting that the set of people involved in
these things should change. I don't think anyone is suggesting we should
stop doing any of these things.
What I am hearing and seeing over and over and over and over is that
people do NOT understand how this all interlocks, which is the right
group for what etc. Mozilla is a mis-mash of very discrete under-used
lists and incredibly general lists.
Don't underestimate the usability of having well titled lists within a
single consolidated discussion infrastructure. It reduces the burden on
the folk trying to map this all out for others to navigate. Since we
don't have a lot of dedicated help on that side, creating the simpler
structures is something we should strive for.
As I said on IRC:
I think this is one of the most important and urgent things for us to do
for the long term health and vitality of this project. We must make
significant strides on this this year, we owe it to ourselves, the
community, and the public that has invested in us.
-Ben
Brendan Eich
> On discussion forums:
>
> Some of the things drivers does:
>
> - pan-gecko leadership
> - confidential contact channel for corporate requirements
> - end game release management
> - 'high council' for some project policy issues.
>
> I don't think anyone is suggesting that the set of people involved in
> these things should change. I don't think anyone is suggesting we should
> stop doing any of these things.
Darin said let's disband drivers, so he doesn't agree on the people
part, and since he didn't acknowledge that drivers did three out of the
four things on your list, it is not clear he agrees on the doing bit either.
But I'm sure Darin values everything on that list, and you're right that
it is hard to tell what drivers does.
Frankly, I *am* out to change the set of people involved in drivers.
The roster is old, some barely contribute, others seem busy in purely
module-owner-purview ways. So I was glad when you said you wanted to
help drive.
> What I am hearing and seeing over and over and over and over is that
> people do NOT understand how this all interlocks, which is the right
> group for what etc. Mozilla is a mis-mash of very discrete under-used
> lists and incredibly general lists.
Yes. We're old, and our policy wonking fell behind our hacking and
struggling for viable organizational structure.
> Don't underestimate the usability of having well titled lists within a
> single consolidated discussion infrastructure. It reduces the burden on
> the folk trying to map this all out for others to navigate. Since we
> don't have a lot of dedicated help on that side, creating the simpler
> structures is something we should strive for.
As I said, we can change names such as "drivers". The argument was
about substance, not surface.
> As I said on IRC:
>
> I think this is one of the most important and urgent things for us to do
> for the long term health and vitality of this project. We must make
> significant strides on this this year, we owe it to ourselves, the
> community, and the public that has invested in us.
I agree. Concrete proposals would help. Please make some, I'm not
going to shoot anything down that preserved needed substance.
/be
Ben Goodger
At the same time as reorganizing our communications, we must revamp the
Mozilla.org website to give it a lift. At present it's a bit obtuse,
there are many pathways to similar but slightly different information,
there is frequently too much or out of date information etc.
The key, I think, is simplifying.
We need to develop a set of requirements for the site, considering it
like a "product", with contributors as the "customers".
Like the world at large there are demographics of contributors. Who are
these folk?
- Engineers
- Community Testers
- Tech Writers
- Early Adopters
- etc.
There are probably many more. Who do we want to spend a lot of effort
targeting?
Once we have that, we figure out what we need to do to help those folk.
There's no 'path of little resistance' for someone interested in helping
us with engineering to get involved. There's at least 1-2 hours of
reading before you can an even remotely figure out how things work.
As a tonal thing, the site also doesn't have an emphasis on "help us
build the future of the Internet" ... it's more "help us fix bug
392442"... I don't know if that's the best way to excite people about
Mozilla.
-Ben
Ben Goodger
> I agree. Concrete proposals would help. Please make some, I'm not
> going to shoot anything down that preserved needed substance.
Thank you.
Here are some ideas:
- get a list of all the lists that aren't mirrored to these newsgroups
(i.e. @mozilla.org lists)
- figure out what they're for
- migrate as many as possible to a single communications infrastructure
(these newsgroups)
- break out overly generic lists like drivers (seeding new lists on this
server or reuse existing ones with drivers members) I'm hoping that the
members of drivers and mozilla2.0 etc can join in this discussion to
help identify all of these, since I only joined recently I don't know
much yet.
- set up some private lists with specific names:
partner-...@mozilla.org or something, note down what they're for
and why they're private.
- figure out how to do project management in a scalable, non-annoying
way on lmo lists - e.g. project management for firefox2, firefox1.5.x, etc.
- figure out how to do release management in a scalable, non-annoying
way on lmo lists - e.g. release management for firefox2, firefox1.5.x, etc.
Once we've tackled these, I think it'd be pretty easy to put together a
page(s) for Mozilla.org that tells people where to ask.
-Ben
Peter Weilbacher
> We have dbaron, roc, bz now in drivers
If bz is in drivers perhaps someone should update
<http://www.mozilla.org/about/drivers>.
Peter.
Robert Kaiser
>> 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.
And Firefox team alone deciding what backends Camino and SeaMonkey ship?
I'm with you, Brendan, that doesn't sound like it would be fitting for
the bigger community. The Mozilla project isn't just Firefox (though we
all know that this one is the most successful and prime product).
>> 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... ;-)
Those are quite hard to navigate through sometimes as well...
Back wehn mozilla.org was developer-centric, it's docs were looked upon
and tried to make this easy. When the domain was also used heavily for
users of the new prime products, those docs rusted. Now that those are
at mozilla.com, we probably can go back to focusing more on projects and
developers on mozilla.org - Which reminds me that we'd need someone to
be "in charge" of mozilla.org and really care about it. Currently those
who want to change something there don't dare to just do it (which is
good) and don't know whom to ask about it (which is bad).
Robert Kaiser
Darin Fisher
> trimming the cc's to the list gateways. /be]
I just replied to both lists last time :-/ Gmail suggested that, and
I didn't look closely at the message headers.
> 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.
Good.
> >> 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).
Wait... I think I was not clear in my point. I wasn't arguing for
module owners working in isolation. No, I meant that it is the
collection of Gecko module owners who are naturally responsible for
Gecko. When you say drivers had to force an issue regarding Gecko,
who exactly are you talking about? I'd bet you were talking about a
couple Gecko module owners who happen to be members of drivers. Let's
see: perhaps you and dbaron? Maybe a few others.
It seems to me that there should be a group responsible for the
direction of Gecko, and it should consist of people who know Gecko
best. Drivers was never defined as such an entity.
The first sentence of http://www.mozilla.org/about/drivers reads:
"Drivers provide project management for mozilla.org milestone releases."
The substring Gecko does not appear anywhere in that document. Out of
the 13 people on that list, maybe only 5 or 6 are in a Gecko
leadership position. And, there are quite a few Gecko leaders who are
not represented there.
> This is not an issue that individual modules owners necessarily solve by
> themselves
Agreed 100%.
> (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).
Who are these drivers again? And, on an issue like this why wouldn't
you naturally want to consult with the folks who are leading Gecko?
(i.e., the module owners who are owners based on merit.)
> > 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.
Of course not! I would consider roc to be one of the Gecko leaders
who should surely be consulted about large changes that impact Gecko.
I think most people who have been involved with this project long
enough would agree.
If I recall correctly, drivers was formed more as a project management
group to actively gate check-ins during crunch time. It also served
the purpose of allowing companies to have a voice in the process.
That's why folks like mkaply (IBM), rjesup (wgate), chofmann
(netscape), asa (mozilla.org), blizzard and caillon (redhat) are on
the list (associations
from the past in some cases). Similarly, it would seem that leaders
for key product areas were invited (e.g., mscott, sspitzer, and beng)
<-- note that mscott and beng are not on the public website, and
sspitzer is long since inactive in this project. Anyways, my point is
that those folks are not in a position to say what is best for Gecko,
but they do have input into such a decision process. It just doesn't
make sense to lump all these things together anymore.
> Seriously, some drivers are pretty uninvolved. The group is neither as
> active nor as crucial as it once was, which again was my point.
Good, we see eye-to-eye here :)
> 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 don't think I intended to argue for anarchy. No, indeed we need to
have an entity responsible for Gecko. Unlike drivers, I think such an
entity should consist only of Gecko leaders (module owners and select
peers, where it is merited). Morph drivers if you think that's
easiest. Whatever works.
> 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.
It should be handled by module owners working together. None of the
issues you just mentioned couldn't be discussed on a public mailing
list, right?
The content meetings seem like the closest thing to a coming together
of Gecko leaders that we've had in recent times. Maybe the
super-reviewer meetings from the distant past were sort-of that as
well. I'm not saying that the content meetings or the "content team"
(if there is such a thing) is the right body to play arbiter for
Gecko, but it seems to be closer to what we need -- a group consisting
of Gecko leaders and strong contributors who can better make decisions
about the future of Gecko.
Here's my suggestion. Create a new group called gecko-leads, who are
responsible for overseeing the development of Gecko. Populate it with
Gecko module owners and any other strong contributors selected by
those module owners perhaps. Create a public mailing list for this
group (gecko...@mozilla.org) and a corresponding private mailing
list (gecko-lea...@mozilla.org) for those times when
security-sensitive matters need to be discussed. Let
gecko...@mozilla.org be the forum for discussing matters such as
Gecko branch planning and rv: numbers. Let is be the place to discuss
whether or not XForms, SVG, MNG, or the like have a shot of being
included in a future version of Gecko. Finally, when the Firefox or
Thunderbird (or other product) teams need something from Gecko, they
will have a clear place to take their concerns: gecko-leads. And,
those concerns will be discussed de-facto in the public on the
gecko...@mozilla.org mailing list.
Let me know if you think I'm wildly off-track here.
> > 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).
Release management is currently being handled by product specific
teams. Again, see bonecho. For the current 1.8 branch, the
collective (and yes disorganized) module owners are gating check-ins.
I raised concern at a bonecho meeting over allowing 1.8 branch
approvals to be disorganized like that. I don't think deferring to
drivers to gate check-ins is the right answer either.
The branch approval process should be something that anyone could
audit easily (with the exception of security sensitive fixes). Bonsai
is great in general, but it doesn't make it so easy to monitor
check-ins. You have to setup a query and run it periodically, etc. A
mailing list designed to track submissions would be nice as it would
give people a way to subscribe to change notifications. When it comes
to auditing approvals, you end up having to run non-trivial bugzilla
queries and so on. There is a high barrier there.
> > 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.
Sure, but that's where transparency helps a lot. If we make it so
that decision making is recorded in public then we have a better
chance of being corrected when we are wrong.
> Someone has to call certain milestone-scheduling and what-is-Gecko
> shots.
gecko-leads!
> Same for what-is-in-Firefox.
bonecho!
> That's not done bottom-up by dozens of module owners. There is no single "Gecko" module that one person owns (with peers).
Agreed. I'm looking for organization too. My last email was light on
that point. Good that you hammer it ;-)
> 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.
Our world was quite complicated during the transition from suite to
aviary. Less so now, it would seem. But, similarly pan-project
issues will undoubtably arrise in the future...
Yes, those things definitely required strong leadership, strong
direction, strong "driving". But, was drivers@ really behind those
successes in leadership? Or, was it just a few members on drivers@?
I think you are saying that we need a decision making body to provide
project wide oversight. Something that could help coordinate the
needs of bonecho with the needs of gecko-leads, for example. Right?
If so, perhaps drivers@ is that group, but it seems like it would be
good to at least refresh its membership, make its operations more
transparent, and break off gecko leadership into its own proper
entity.
> 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.
Yeah, I'm buying the argument that we need such a group tasked with
this kind of responsibility. The problem is that drivers is currently
overloaded to mean too many different things. It's public membership
is clearly not in sync with what you are saying, and the fact that it
has a private membership is troubling. Transparency please! :-)
> 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.
Agreed.
> > 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.
MNG and SVG should have been, could have been, aptly handled by gecko
leads. I'm going to guess that gecko leaders were the ones making
those decisions, not Asa for example (no offense, Asa!).
> > 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.
I never said that. I think there is a clear line between those
products and the Gecko that they depend on. Just as there is a team
leading Firefox, there should be a team leading Gecko.
> 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.
Agreed.
> > 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.
No, I'm not saying that. I'm saying that the bonecho team exists to
create Firefox 2. That's where things start. They defined the
requirements for that product. That led to the decision to base
Firefox 2 on Gecko 1.8.x intead of Gecko 1.9. My point is that the
process that led to those kinds of decisions seems to be a good one.
How much of that involved drivers? Honestly, I don't know because
drivers is an opaque entity, but from what I could tell the decision
was made based primarily on a desire by the bonecho team to use a
stable Gecko so they could release quickly. I believe the decision
involved discussions with folks who are involved with Gecko
development to understand and formalize how Gecko 1.8.1 would work.
This seems like the "firefox team" interacting with the "gecko team"
in a healthy manner.
> 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.
Hey, I think it's great to analyze that experience. Again, I have no
idea how much drivers was involved in that issue. (That's part of the
problem here!) Looking at that experience, I would guess that it
would have helped if we'd have had strong gecko leadership in the form
of something like the gecko-leads group that I proposed. Then, the
front-end team would have had a place to take their needs to. Gecko
leads would have been responsible for making a good call (based on the
needs of its customer) on bfcache and window targeting since those are
in its domain.
> > 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.
Yes, but MOZILLA_1_8_BRANCH is not the trunk! We're talking about
Gecko 1.8.1 here, with specific rules: like, no interface changes.
We're trying to be conservative on the 1.8 branch when it comes to
Gecko. That requires some organization amongst module owners to all
be on the same page w.r.t. what is approved and what is not.
> > 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.
Hrm? Maybe, but when I look at the current list of drivers, I don't
see how you can think that those people are in a position to say what
is best for FF2. Some of them, yes definitely. The group needs
serious reform at least.
> 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?
OK, sure. However, we should definitely stop convoluting pan-project
management with gecko leadership.
> > They should work closely with the
> > module owners to review patch approval requests.
>
> Drivers do this and have historically done this. Same wheel.
Yes
> > 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.
Yeah, I agree... I really meant something different that anyone could
subscribe to if they were interested in auditing approvals (and
perhaps submissions as well).
> 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.
Exactly. The biggest problem with drivers is lack of transparency!
Because of that, myself and many others have no idea what goes on
there. That ain't good for the health of the mozilla project.
> 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.
OK, invent drivers...@mozilla.org and open up
dri...@mozilla.org. Encourage everyone to _only_ use
drivers-private@ when necessary.
> >> 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?
Such a page should perhaps also list the private mailing lists, since
we can at least be upfront about the stuff that we can't discuss in
the open ;-)
Thanks for taking the time to respond to my email. I feel strongly
that reform of drivers is needed, but unfortunately the last time I
brought up the issue, nothing happened. Will something actually
happen this time?
-Darin
Mike Beltzner
> At the same time as reorganizing our communications, we must revamp the
> Mozilla.org website to give it a lift. At present it's a bit obtuse,
> there are many pathways to similar but slightly different information,
> there is frequently too much or out of date information etc.
Keeping the information fresher means making it easier to edit and
update the information. I think that less of mozilla.org should be based
on CVS checkins and edits, that more content should be moved to
wiki.mozilla.org. The mozilla.org site should be a "welcome to the
project, what aspect are you interested in?" site, with pointers off to
the various homes on the wiki for those aspects. Deb Richardson has
recently pointed out (in mozilla.dev.mdc) the benefits of using a wiki
over a static website that requires patch reviews and CVS commits.
> The key, I think, is simplifying.
Yes, well, that too :)
> Like the world at large there are demographics of contributors. Who are
> these folk?
>
> - Engineers
> - Community Testers
> - Tech Writers
> - Early Adopters
> - etc.
>
> There are probably many more. Who do we want to spend a lot of effort
> targeting?
I think it's easier to segment these groups into task domain than
professional domain in order to prevent over-fragmentation. So,
- designing & developing
- testing & providing feedback
- promoting & advocating
- documenting & supporting
Any others?
> As a tonal thing, the site also doesn't have an emphasis on "help us
> build the future of the Internet" ... it's more "help us fix bug
> 392442"... I don't know if that's the best way to excite people about
> Mozilla.
Agreed. Also, we should ensure that we're welcoming and informal in
tone. A common thing I've heard from would-be contributors is that they
never realized that people "just like me" can actually add a lot of
value and thrust.
cheers,
mike
--
mike beltzner, user experience lead, mozilla corporation
Jon Smirl
> >> 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).
It seems to me that most of the pressure for this would disappear if
MNG, XForms, SVG 1.2, etc could be installed as on-demand modules
(full fledged Gecko chunks, not plugins). It's fine with me if the
modules have to be recompiled for Gecko 1.7, 1.8, 1.9, etc... That
would be the module owner's problem to provide versions for the
various engines and platforms. Only the most popular modules would
come preinstalled. Installable modules also provides a path for
removing features.
Is there any possibility of an architecture like this happening? Would
it be general enough to bring NVU and Flock back into the main code
base?
--
Jon Smirl
jons...@gmail.com
Darin Fisher
> On 3/10/06, Brendan Eich <bre...@meer.net> wrote:
> > Darin Fisher wrote:
> > >> 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).
>
> MNG, XForms, SVG 1.2, etc could be installed as on-demand modules
> (full fledged Gecko chunks, not plugins). It's fine with me if the
> modules have to be recompiled for Gecko 1.7, 1.8, 1.9, etc... That
> would be the module owner's problem to provide versions for the
> various engines and platforms. Only the most popular modules would
> come preinstalled. Installable modules also provides a path for
> removing features.
>
> Is there any possibility of an architecture like this happening? Would
> it be general enough to bring NVU and Flock back into the main code
> base?
Gecko is highly modular, but not always modular in the right way. It
does take some design effort to make better APIs, and I think that
contributions of that sort are usually welcome. Just take a look at
XTF for example. While some would argue that it should probably have
been done differently (it has so much in common with XBL), it was the
prime enabler that allowed XForms to be developed as an extension
exactly as you have described.
-Darin
Ben Goodger
> Back wehn mozilla.org was developer-centric, it's docs were looked upon
> and tried to make this easy. When the domain was also used heavily for
> users of the new prime products, those docs rusted.
To be fair, those docs have always been pretty rusty.
Browse through www.apache.org or subversion.tigris.org for comparison ;-)
-Ben
Boris Zbarsky
> It seems to me that most of the pressure for this would disappear if
> MNG, XForms, SVG 1.2, etc could be installed as on-demand modules
That can already be done with MNG, I believe. At least I recall biesi doing a
fair amount of work to make this possible.
XForms is already installed exactly like this.
SVG is harder because it changes so much behavior of basic layout code; layout
simply wasn't designed with an eye to bolting on completely new layout
algorithms and renderers. I'm not sure it's really worth redesigning around
this criterion, frankly. That said, it may be possible to do SVG1.2 as an
on-demand module on top of something sane like SVG1.1...
> Is there any possibility of an architecture like this happening? Would
> it be general enough to bring NVU and Flock back into the main code
> base?
I have no idea what Flock is doing nor do I have a good idea of what the scope
of the NVU changes is. Some of the NVU stuff is just bugfixes or core
improvements need to make it back into the trunk. Most of the rest is exactly
an "extension" built on top of those. So I think NVU is already where you want
it to be -- the problems there are that no one's merging, not that it can't be done.
-Boris
Jon Smirl
> On 3/10/06, Jon Smirl <jons...@gmail.com> wrote:
> > On 3/10/06, Brendan Eich <bre...@meer.net> wrote:
> > > Darin Fisher wrote:
> > > >> 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).
> >
> > MNG, XForms, SVG 1.2, etc could be installed as on-demand modules
> > modules have to be recompiled for Gecko 1.7, 1.8, 1.9, etc... That
> > would be the module owner's problem to provide versions for the
> > various engines and platforms. Only the most popular modules would
> > come preinstalled. Installable modules also provides a path for
> > removing features.
> >
> > it be general enough to bring NVU and Flock back into the main code
> > base?
>
> does take some design effort to make better APIs, and I think that
> contributions of that sort are usually welcome. Just take a look at
> XTF for example. While some would argue that it should probably have
> been done differently (it has so much in common with XBL), it was the
> prime enabler that allowed XForms to be developed as an extension
> exactly as you have described.
A policy decision could be made that the only way to add new
capabilities to gecko is to first build it as an XTF module. Is it
feasible to encourage the conversion of SVG to XTF? Of course the
appropriate would need to be done to make XTF and related APIs general
enough.
Personally I would really like to see NVU brought back into the main
stream. xulrunner will help but I still don't want two gecko engines
that are 95% identical. In the long run I believe an optional enhanced
editor component is a valuable addition (think Google and the Writely
acquisition).
Has XTF been extended to allow on-demand installation yet? Last time I
checked it hadn't. Best solution for me would be to browse to a page
containing SVG or Xforms and get a popup asking for permission to
install the added module.
--
Jon Smirl
jons...@gmail.com
Ben Goodger
> responsible for overseeing the development of Gecko. Populate it with
> Gecko module owners and any other strong contributors selected by
> those module owners perhaps. Create a public mailing list for this
> group (gecko...@mozilla.org) and a corresponding private mailing
> list (gecko-lea...@mozilla.org) for those times when
> security-sensitive matters need to be discussed.
So formalize that into security-specific list or something. We don't
have (or at least I don't want) private firefox discussion lists. We
have a pan-project security for security issues and firefox issues are
handled there.
Creating gecko-leads-private begs for people to think of reasons to use
it, not get into the habit of using certain lists for certain things.
-Ben
Boris Zbarsky
> A policy decision could be made that the only way to add new
> capabilities to gecko is to first build it as an XTF module.
Actually, we'd kinda like to get rid of XTF... ;)
> Is it feasible to encourage the conversion of SVG to XTF?
Depends on how slow do you want your SVG to be. XTF is not very performant, imo.
> Of course the appropriate would need to be done to make XTF and related APIs general
> enough.
Generality and performance often conflict..... That's one reason some of Gecko
is not more general and modular. :(
> Personally I would really like to see NVU brought back into the main
> stream.
Then start merging patches. The problem with NVU is not lack of modularity but
changes to existing modules that never get merged to trunk, imo.
-Boris
Jon Smirl
> > Personally I would really like to see NVU brought back into the main
> > stream.
>
> Then start merging patches. The problem with NVU is not lack of modularity but
> changes to existing modules that never get merged to trunk, imo.
I don't work on NVU but I do use it and have the source on my machine.
Has Mozilla considered moving to a peer based source control system
like git (used by the linux kernel)? CVS makes it very easy to get
into the problem NVU is in. From his blog he is complaining that drift
in the source is making it too hard to merge. I've gotten into that
same problem myself numerous times with CVS repositories where I don't
have commit access.
When you don't have commit access you have to run a local CVS to track
your own changes. But now there is no simple way to pull the changes
down from the main CVS and merge them. Since merging is a pain drift
starts to happen. Tools like git (or SVN/Bitkeeper/etc) don't have
this problem. They can track the local and remote repositories equally
and do three way merges. That makes it easy to sync the local and
remote repositories every day before things get too far out of sync.
Insiders with CVS commit access never see this problem so they don't
understand what all of the fuss is about.
--
Jon Smirl
jons...@gmail.com
Darin Fisher
> > Here's my suggestion. Create a new group called gecko-leads, who are
> > responsible for overseeing the development of Gecko. Populate it with
> > Gecko module owners and any other strong contributors selected by
> > those module owners perhaps. Create a public mailing list for this
> > group (gecko...@mozilla.org) and a corresponding private mailing
> > list (gecko-lea...@mozilla.org) for those times when
> > security-sensitive matters need to be discussed.
>
> So formalize that into security-specific list or something. We don't
> have (or at least I don't want) private firefox discussion lists. We
> have a pan-project security for security issues and firefox issues are
> handled there.
Hey, that sounds even better to me. So, just a gecko...@mozilla.org then :-)
-Darin
Boris Zbarsky
> Has Mozilla considered moving to a peer based source control system
> like git (used by the linux kernel)?
Some people have. That's not relevant here, though; see below.
> From his blog he is complaining that drift
> in the source is making it too hard to merge.
Sure. If you go off on a branch for a year or so merging is hard when you
decide to finally do it.
> I've gotten into that
> same problem myself numerous times with CVS repositories where I don't
> have commit access.
Except Daniel has commit access to mozilla.org CVS. He's one of the Editor
module owners, in fact.
> When you don't have commit access you have to run a local CVS to track
> your own changes.
Sure, but that's not what happened here.
> Insiders with CVS commit access never see this problem so they don't
> understand what all of the fuss is about.
Yep. Given the above, I repeat my claim that the issue with NVU is not a
technological issue.
-Boris
Brendan Eich
Where's the wiki interface to that page? :-P.
/be
Brendan Eich
Brendan Eich
I don't think this is enough.
cvs.mozilla.org is not cleanly divided into "Gecko", "Firefox", and
"other stuff we will ignore in this discussion". "Gecko" itself is big
and includes subsidiary modules that stand alone (e.g. SpiderMonkey).
Our front-to-back, end-to-end APIs are not all well-documented or even
understood. I'm talking about all APIs here, wherever defined by a .idl
file or (shudder) a .h file.
Global thinking is required to meet several goals:
* A Gecko identified by user-agent comment with an rv: value that is
consistent for web authors, compelling against the competition, and able
in concert with other browser vendors to move the web forward.
* A Firefox that keeps on kicking ass and taking names, in the face of
competition from IE7 (backed by MS's billions) and "coopetition" with
the non-IE browsers.
* XULRunner as the future common runtime underlying Firefox and other
new-toolkit XUL apps.
* Thunderbird, Minimo, Camino, SeaMonkey, etc. (not to slight these, but
not to leave them out entirely).
Then there are the project management issues surrounding the common
trunk milestone plan we all share.
Sharing a continuously integrating trunk implies shared effort planning
and managing it, which in any large group effort means some leaders
taking a global view, not just wearing "Gecko" or "Firefox" lead hats.
That group of leaders with global view has been drivers. Not Gecko
drivers, and certainly not Firefox drivers -- but not entirely divorced
from Firefox project and release management either.
/be
Brendan Eich
> Jon Smirl wrote:
>> It seems to me that most of the pressure for this would disappear if
>> MNG, XForms, SVG 1.2, etc could be installed as on-demand modules
Boris answered this, but I wanted to amplify that even when this can be
done, and it can be and is being done, there is still controversy about
what to bundle by default, and drivers have had to mediate and judge to
resolve that conflict.
>> Is there any possibility of an architecture like this happening? Would
>> it be general enough to bring NVU and Flock back into the main code
>> base?
>
> I have no idea what Flock is doing
We hear nothing from Flock. Our planning docs are all wiki'd. They are
welcome to participate.
> nor do I have a good idea of what the
> scope of the NVU changes is. Some of the NVU stuff is just bugfixes or
> core improvements need to make it back into the trunk. Most of the rest
> is exactly an "extension" built on top of those. So I think NVU is
> already where you want it to be -- the problems there are that no one's
> merging, not that it can't be done.
I think NVU's changes should be landed on a real schedule. I'll ask
Daniel what that entails. It may be that some emoluments from somewhere
will help get this done.
/be
Darin Fisher
Brendan,
You already convinced me that some pan-project entity is required to
oversee the mozilla project. I'm with you on that. Let's talk about
how drivers will be reformed to best meet the goals you listed above.
How can its decision making be made more transparent?
On the topic of gecko-leads, do you really feel that drivers should
also be the entity that leads Gecko development? I don't. Drivers
may have valuable input, sure. I think Gecko development should be
led by a group that consists of people who work on Gecko. The
membership of drivers is inconsistent with that. If drivers is
oriented to the goals you listed above, which makes sense to me, then
there is certainly room for a team of folks who lead Gecko
development, just like there is a group of folks who lead Firefox
application development. Make sense?
-Darin
Brendan Eich
>
> Brendan,
>
> You already convinced me that some pan-project entity is required to
> oversee the mozilla project. I'm with you on that.
Ok sorry -- I'm having newsreader problems of some sort. I see only
some posts. Maybe I have to nuke a .msf file or something...
> Let's talk about
> how drivers will be reformed to best meet the goals you listed above.
> How can its decision making be made more transparent?
Need an actionable plan to deal with:
1. Routing bugzilla-daemon-request traffic so as not to violate the
security bug policy
(http://www.mozilla.org/projects/security/security-bugs-policy.html).
2. Need a private list for vendor-NDA'd, "HR", and other confidential
issues, following Ben's proposal for the don't-use-unless-you-mean-it
naming convention (we tried this in past lives at Netscape and AOL, it
only goes so far, but I'm game again).
3. The name. Tradition and law of least effort favors keeping drivers,
but I'm open to something better, so long as it's not too boring or
overlong.
> On the topic of gecko-leads, do you really feel that drivers should
> also be the entity that leads Gecko development?
Drivers isn't about leading Gecko development, I didn't say that it was.
Please, no straw men. It seemed you were raising the gecko-leads idea
as an alternative to drivers, and I was pointing out what drivers does.
> I don't. Drivers
> may have valuable input, sure. I think Gecko development should be
> led by a group that consists of people who work on Gecko.
Sure, there already is a de-facto group: bz, dbaron, roc, jst, sicking,
a few other long-standing heavyweights. I leave it to them to respond
to the idea of formalizing gecko-leads.
I have one question for you, though: should we map Gecko into despot, as
a mega-module? Or just make a hand-maintained list of people's names
(and emails for spammers to harvest)? More generally, what concrete
form would gecko-leads take, that does not already exist?
/be
Brendan Eich
> Wait... I think I was not clear in my point. I wasn't arguing for
> module owners working in isolation. No, I meant that it is the
> collection of Gecko module owners who are naturally responsible for
> Gecko. When you say drivers had to force an issue regarding Gecko,
> who exactly are you talking about? I'd bet you were talking about a
> couple Gecko module owners who happen to be members of drivers. Let's
> see: perhaps you and dbaron? Maybe a few others.
No. I was talking about, for example (not the only case), whether
Camino ships with SVG disabled, or Minimo with MathML disabled (if so,
with what user-agent).
This involves at least two parties other than drivers: Gecko leads
(perhaps on drivers, doesn't matter) and app leads.
> The first sentence of http://www.mozilla.org/about/drivers reads:
> "Drivers provide project management for mozilla.org milestone releases."
>
> The substring Gecko does not appear anywhere in that document.
Yes, but the Mozilla 1.8 milestone induces the Gecko rv: 1.8 value in
the user-agent string, semi-automatically.
It's all connected, man! ;-)
> Out of
> the 13 people on that list, maybe only 5 or 6 are in a Gecko
> leadership position. And, there are quite a few Gecko leaders who are
> not represented there.
How many cooks do you have in your kitchen?
>> This is not an issue that individual modules owners necessarily solve by
>> themselves
>
> Agreed 100%.
But I think you just renamed terms and disagreed. The issue is not
"Gecko" vs. itself in deciding what rv: value means, or sub-components
of Gecko fighting in ways that Gecko leads might mediate/adjudicate. The
potential for conflict arises at all levels, including globally.
>> (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).
>
> Who are these drivers again?
C'mon, at that point the list was well-maintained directly on the
roadmap page, and MNG fans pretty much knew where to mail their complaints.
> And, on an issue like this why wouldn't
> you naturally want to consult with the folks who are leading Gecko?
> (i.e., the module owners who are owners based on merit.)
We did. As I noted, the situation was that pav, acting only as libpr0n
module owner, turned off MNG and CVS removed it because its glue with
imglib was unowned, and bugs were abounding.
That escalated past any putative Gecko leads directly to drivers. That
is kosher, since the Mozilla technical delegation/buck-passing flow is
owners <->
drivers on behalf of staff, for project management problems <->
staff for non-driver things and for appealing driver verdicts <->
me
Does this help?
/be
Christian Biesinger
> Where's the wiki interface to that page? :-P.
https://doctor.mozilla.org/?file=mozilla-org/html/about/drivers.html
:-P
Ben Goodger
> 3. The name. Tradition and law of least effort favors keeping drivers,
> but I'm open to something better, so long as it's not too boring or
> overlong.
The name "drivers" IMO is part of the problem. It in no way describes
what goes on there. I'm not proposing
"thing-only-an-idiot-wo...@mozilla.org" but don't
think sane shorter, more descriptive alternatives are a big deal,
especially in this world of autocomplete.
-Ben
L. David Baron
> It seems to me that most of the pressure for this would disappear if
> MNG, XForms, SVG 1.2, etc could be installed as on-demand modules
> (full fledged Gecko chunks, not plugins). It's fine with me if the
> modules have to be recompiled for Gecko 1.7, 1.8, 1.9, etc... That
> would be the module owner's problem to provide versions for the
> various engines and platforms. Only the most popular modules would
> come preinstalled. Installable modules also provides a path for
> removing features.
Splintering Gecko would make Gecko harder for Web authors to target,
which reduces the effect of our market share on making pages more likely
to work in Gecko, and hurts our users.
> Is there any possibility of an architecture like this happening? Would
I certainly hope not.
Modularity to help maintainability and correctness of programs may be a
good thing, but that doesn't mean we want to pass the choice of modules
on to our users.
> it be general enough to bring NVU and Flock back into the main code
> base?
I don't think it has anything to do with either of those, as has already
been mentioned.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Jon Smirl
> On Friday 2006-03-10 14:10 -0500, Jon Smirl wrote:
> > MNG, XForms, SVG 1.2, etc could be installed as on-demand modules
> > (full fledged Gecko chunks, not plugins). It's fine with me if the
> > modules have to be recompiled for Gecko 1.7, 1.8, 1.9, etc... That
> > would be the module owner's problem to provide versions for the
> > various engines and platforms. Only the most popular modules would
> > come preinstalled. Installable modules also provides a path for
> > removing features.
>
> which reduces the effect of our market share on making pages more likely
> to work in Gecko, and hurts our users.
I don't see that this is splintering. If you browse to a page that
needs the module you would get a prompt to install it. The model works
well for web standards that are not in widespread use - things like
chemical markup language or musical notation. I would put SVG in this
category currently - the jury is still out on whether SVG or something
like canvas is going to win.
99% of the time people will install the module because they want to
see the content. People only stop installing modules when they think
something is wrong - like running out of disk space, rumors of a virus
in the module, annoying features of the model, etc. How many poeple
reject SSL prompts?
Splintering would be multiple Firefox versions with no mechanism for
automatically converting one to another. That's what we have right now
- builds with/without SVG enabled, etc.
Of course the most popular modules would come pre-installed in the
core download. If you take this to an extreme, minimo could be just
the bare core. Then by adding lots of other modules you could build up
to Firefox.
>
> > Is there any possibility of an architecture like this happening? Would
>
> I certainly hope not.
>
> Modularity to help maintainability and correctness of programs may be a
> good thing, but that doesn't mean we want to pass the choice of modules
> on to our users.
Ok, I'm gagging on that one. As a user I will say I can not stand
Flash. I do not want it on my machine and if it wasn't for Flashbock I
wouldn't use Firefox. I couldn't care less about the content I can't
see because I have Flash disabled; the downside of having annoying
blinking ads on every page far outweighs the content I miss. The Flash
module has violated my trust that it will add positively to the
browser experience.
--
Jon Smirl
jons...@gmail.com
Brendan Eich
Need... Concrete... Proposals...!
project-m...@mozilla.org? Barf-o-rama.
global-o...@mozilla.org? sounds like big-b...@mozilla.org.
Someone throw something out, quick!
/be
Brendan Eich
> I don't see that this is splintering. If you browse to a page that
> needs the module you would get a prompt to install it. The model works
> well for web standards that are not in widespread use - things like
> chemical markup language or musical notation. I would put SVG in this
> category currently - the jury is still out on whether SVG or something
> like canvas is going to win.
Ok, you want more plugins. Got it.
>> Modularity to help maintainability and correctness of programs may be a
>> good thing, but that doesn't mean we want to pass the choice of modules
>> on to our users.
>
> Ok, I'm gagging on that one. As a user I will say I can not stand
> Flash.
You are far from a typical user. But wait, what's wrong with Flash that
is right with an XForms or SVG1.2 plugin? Those could be used for ads too.
/be
Jon Smirl
> >> good thing, but that doesn't mean we want to pass the choice of modules
> >> on to our users.
> >
> > Ok, I'm gagging on that one. As a user I will say I can not stand
> > Flash.
>
> You are far from a typical user. But wait, what's wrong with Flash that
> is right with an XForms or SVG1.2 plugin? Those could be used for ads too.
It not that ads that bother me. I don't run a general ad blocking
program. I'm in favor of advertising to support webs sites. I even
click on ads and use the search bar.
What I can't stand are the unstoppable animations. I want to read the
content on the page and not be distracted by idiotic cartoon
characters waving at me.
--
Jon Smirl
jons...@gmail.com
Boris Zbarsky
> What I can't stand are the unstoppable animations.
SVG has those aplenty. :(
-Boris
Jon Smirl
Can we hook Flash and SVG up to the stop button and make it work? Ads
that annoy to the point that the user wants to remove the display
technology aren't selling anything.
--
Jon Smirl
jons...@gmail.com
Samuel Sidler
> Need... Concrete... Proposals...!
A full proposal for you. :)
I propose the following, with an explanation of the points below:
1) Creation of gecko-leads@m.o to lead Gecko development and overall planning.
2) Keeping drivers@m.o where it is, but opening it up for others to see.
3) Maintaining information on wiki.m.o regarding what major decisions both
gecko-leads@ and drivers@ are making.
Explanation:
1) gecko-leads@m.o will be a newsgroup (like this one) and will be led by a
select dozen (or so) who are responsible for Gecko development.
The list should include at least one member from each major product that
mozilla.org releases, including Firefox, Thunderbird, SeaMonkey, and Camino
(probably the project leads). Should other projects (like Nvu, Flock, and
Songbird) join mozilla.org, gecko-leads would determine if they too should
have a representative on the gecko-leads team.
The remainder of the list would be made up of "supermodule owners" as defined
by the various modules at mozilla.org/owners.html. The supermodules would
exist in name only -- for purposes of gecko-leads only -- and the
representatives from each grouping would oversee the Gecko plan and
development of the modules inside of it. I, of course, am not the appropriate
person to choose how such supermodules would be grouped, but something along
the lines of: Graphics, Rendering, Editor, Embedding, JavaScript, etc. (Again,
I'm not the right person to determine these.)
2) drivers@m.o would be opened up for others to see the processes of. It
should be "reformed" with appropriate people if some are currently not active.
The open group would drive releases as they do now and do whatever else they
currently do in secret (joke) in public. A secondary list could be created for
private discussion, if needed.
3) To provide even more transparency, the wiki would include information on
what decisions both gecko-leads@ and drivers@ are making. This, of course,
doesn't need to be mundane decisions, but should be along the lines of what
Firefox is currently doing with its weekly meetings. This gives the community
an easier point of entry, as opposed to sifting through the newsgroups to see
what is happening.
So... this proposal is definitely not perfect, but I'd appreciate comments and
suggestions for improvement. If I understood most of the discussion correctly,
this is mostly what is being requested.
Samuel Sidler
L. David Baron
> 1) gecko-leads@m.o will be a newsgroup (like this one) and will be led by a
> select dozen (or so) who are responsible for Gecko development.
>
> The list should include at least one member from each major product that
> mozilla.org releases, including Firefox, Thunderbird, SeaMonkey, and Camino
> (probably the project leads). Should other projects (like Nvu, Flock, and
I thought the point of the proposal for gecko-leads was that it *not*
(as drivers does) have non-Gecko hackers on it. If it's going to have
representatives from all the apps, how is it different from drivers?
Christian Biesinger
> Can we hook Flash and SVG up to the stop button and make it work?
Not in case of flash (unless you want to remove the plugin content when
stop is pressed).
It could probably be done with other dynamic stuff, by killing all
timers or something...
Samuel Sidler
> I thought the point of the proposal for gecko-leads was that it *not*
> (as drivers does) have non-Gecko hackers on it. If it's going to have
> representatives from all the apps, how is it different from drivers?
Arguably, it won't have non-Gecko hackers on it. mozilla/browser,
mozilla/mailnews, etc will have "positions" on gecko-leads@ which cover Fx and
Tb, respectively. Same with Sm and Cm (with the exception that Cm isn't listed
on the modules page). These are the people, along with other major modules,
who have the most vested in Gecko.
I am have not understood parts of the conversation correctly, apologies if I
didn't. This differs from drivers@ in its role only and gives those who have
the most vested in Gecko (and mozilla.org) a determination of where it goes.
Drivers can be much less targeted to do their job. They don't need to be as
tied to Gecko, so to speak. Some who are part of drivers@ now (according to
the page at least) don't have nearly as much vested in Gecko... which is fine,
if leadership moves to gecko-leads@.
Samuel Sidler
Robert O'Callahan
> Here's my suggestion. Create a new group called gecko-leads, who are
> responsible for overseeing the development of Gecko. Populate it with
> Gecko module owners and any other strong contributors selected by
> those module owners perhaps. Create a public mailing list for this
> group (gecko...@mozilla.org) and a corresponding private mailing
> list (gecko-lea...@mozilla.org) for those times when
> gecko...@mozilla.org be the forum for discussing matters such as
> Gecko branch planning and rv: numbers. Let is be the place to discuss
> whether or not XForms, SVG, MNG, or the like have a shot of being
> included in a future version of Gecko. Finally, when the Firefox or
> Thunderbird (or other product) teams need something from Gecko, they
> will have a clear place to take their concerns: gecko-leads. And,
> those concerns will be discussed de-facto in the public on the
> gecko...@mozilla.org mailing list.
>
> Let me know if you think I'm wildly off-track here.
I would prefer to have public pan-Gecko discussion in a newsgroup. It
could even just go in mozilla.dev.planning. My general feeling is that
these days it's better to err on the side of having fewer, more
overloaded fora. I would use this group to announce upcoming major
changes that will affect other applications and modules.
What's important about the drivers discussion is IMHO not a question of
mailing lists, but power: who has the power to make decisions about
Gecko --- to cut the endless threads and decide, for example, whether or
not a module is part of "official Gecko", or whether a module owner has
gone off the rails. We need to know who this group is. The group needs
a name. If more than one person, it needs a forum for private discussion.
IMHO this group should be separated from release management. It's no
trouble to call in module owners for help evaluating bugs as required.
Rob
Gervase Markham
> What I can't stand are the unstoppable animations. I want to read the
> content on the page and not be distracted by idiotic cartoon
> characters waving at me.
Can we fix it so "Escape" pauses Flash just as it stops animated GIFs?
Gerv
Gervase Markham
> You already convinced me that some pan-project entity is required to
> oversee the mozilla project. I'm with you on that.
Presumably you mean technical oversight?
It strikes me that we used to have a group concerned with the big issues
Ben's been raising (e.g. in his "Open House" thread) about project
communication and coordination. It was called "st...@mozilla.org".
While we're tackling these questions, let's look at that one as well :-)
Gerv
Gervase Markham
> 1) gecko-leads@m.o will be a newsgroup (like this one) and will be led by a
> select dozen (or so) who are responsible for Gecko development.
I think it's confusing to have a list called "gecko-leads" which does
not just have gecko-leads on it. Why not call it just "gecko" (or
rather, mozilla.dev.tech.gecko)? If you also want to have a list of
people who are in charge of the list, put it on the wiki.
> 2) drivers@m.o would be opened up for others to see the processes of. It
> should be "reformed" with appropriate people if some are currently not active.
> The open group would drive releases as they do now and do whatever else they
> currently do in secret (joke) in public. A secondary list could be created for
> private discussion, if needed.
You're getting more vague as you go along... ;-)
Gerv
Darin Fisher
Rob,
I think you hit the nail on the head. I agree. Historically, drivers was the
entity that had final say over changes made to the Mozilla codebase. Back
then we only had one product, the Mozilla Suite. Today, we have many
sub-projects, each with their owner leadership structure. For example,
when it comes to Firefox UI, drivers has no power. However, when it
comes to questions about what goes into Gecko or doesn't, drivers is
still relevant. Defining the power structure is important.
>From what I can tell, a line has been hardening between the Mozilla platform
and the applications built on top of that platform. Gecko is a big part of that
platform. Perhaps what is needed is a group of "platform drivers" who will
be responsible for making the final decision on issues concerning the
direction of the Mozilla platform. In my opinion, this group should consist of
the owners for the modules that make up the Mozilla platform.
I believe that this isn't a big shift from where we are today. In an ad-hoc
fashion, we've been running this way for a while. I think it's worth it to
better formalize "platform drivers" as a group who will be final arbiter for
changes to the Mozilla platform.
-Darin
Ben Goodger
> I believe that this isn't a big shift from where we are today. In an ad-hoc
> fashion, we've been running this way for a while. I think it's worth it to
> better formalize "platform drivers" as a group who will be final arbiter for
> changes to the Mozilla platform.
What is the definition of "platform" - just Gecko? Gecko + XULRunner?
-Ben
Darin Fisher
> On 3/12/06, Robert O'Callahan <rob...@ocallahan.org> wrote:
>
> I think you hit the nail on the head. I agree. Historically, drivers was the
> entity that had final say over changes made to the Mozilla codebase. Back
> then we only had one product, the Mozilla Suite. Today, we have many
> sub-projects, each with their owner leadership structure. For example,
> when it comes to Firefox UI, drivers has no power. However, when it
> comes to questions about what goes into Gecko or doesn't, drivers is
> still relevant. Defining the power structure is important.
>
> From what I can tell, a line has been hardening between the Mozilla platform
> and the applications built on top of that platform. Gecko is a big part of that
> platform. Perhaps what is needed is a group of "platform drivers" who will
> be responsible for making the final decision on issues concerning the
> direction of the Mozilla platform. In my opinion, this group should consist of
> the owners for the modules that make up the Mozilla platform.
>
> fashion, we've been running this way for a while. I think it's worth it to
> better formalize "platform drivers" as a group who will be final arbiter for
> changes to the Mozilla platform.
>
>
BTW, to clarify, I'm suggesting that platform-drivers@ or platform-leads@
is a better way to go than gecko-leads@.
-Darin
Darin Fisher
platform on which applications like Firefox and Thunderbird are built.
That includes the web platform, the XUL toolkit, our embedding APIs,
etc. It is what LibXUL (http://wiki.mozilla.org/XUL:Lib_XUL) is
trying to deliver.
-Darin
Ben Goodger
> I would prefer to have public pan-Gecko discussion in a newsgroup. It
> could even just go in mozilla.dev.planning. My general feeling is that
> these days it's better to err on the side of having fewer, more
> overloaded fora. I would use this group to announce upcoming major
> changes that will affect other applications and modules.
That sounds good (fewer fora)... just as long as it's easy for someone
to intuitively figure out where to go.
Some ideas:
We've been doing firefox feature analysis & design discussion in
mozilla.dev.apps.firefox. I think it's important that if you're going to
not do all discussion about all projects in the same forum, the forum
you use should have your component name as part of the list name, so
people can figure it out. So if gecko discussion is to be separate from
firefox or thunderbird discussion for instance (and I think there'll be
enough of it that it should be) then it should happen on a list with
'gecko' in the name.
The difficulty is that the current ng hierarchy has .apps. and .tech.
groups, with a lot of peers. This may be difficult to navigate - I think
this is why you suggest having fewer more overloaded groups. I'm not
sure what the best solution is for this to prevent people posting in
areas that aren't read much.
More rah-rah:
As someone who doesn't do a lot of Gecko development, I like the idea of
having more discussion in newsgroups and design documents, so I can read
up at my leisure and follow along with things that are going on, what
people think are important, etc. Right now to do this I'd have to follow
along on IRC, bugs, etc. which is harder. I think focusing technical
discussion more on the ngs would have a positive impact on the number of
people that know about Gecko development, its conventions, etc. I think
lots of people are very interested, they just lack the bandwidth to keep
up with the appropriate fora right now.
-Ben
Benjamin Smedberg
> Robert O'Callahan wrote:
>> I would prefer to have public pan-Gecko discussion in a newsgroup. It
>> could even just go in mozilla.dev.planning. My general feeling is that
>> these days it's better to err on the side of having fewer, more
>> overloaded fora. I would use this group to announce upcoming major
>> changes that will affect other applications and modules.
>
> That sounds good (fewer fora)... just as long as it's easy for someone
> to intuitively figure out where to go.
>
> Some ideas:
>
> We've been doing firefox feature analysis & design discussion in
> mozilla.dev.apps.firefox. I think it's important that if you're going to
> not do all discussion about all projects in the same forum, the forum
> you use should have your component name as part of the list name, so
> people can figure it out. So if gecko discussion is to be separate from
> firefox or thunderbird discussion for instance (and I think there'll be
> enough of it that it should be) then it should happen on a list with
> 'gecko' in the name.
I would personally prefer to deprecate the "gecko" name as vague, and go
with the "mozilla platform" or "mozilla toolkit". My preferred group would
be m.d.platform. Leave m.d.planning for scheduling/releasing/meta-discussion
issues, which really seems where this discussion ought to be.
--BDS
Ben Goodger
> I would personally prefer to deprecate the "gecko" name as vague, and go
> with the "mozilla platform" or "mozilla toolkit". My preferred group
> would be m.d.platform. Leave m.d.planning for
> scheduling/releasing/meta-discussion issues, which really seems where
> this discussion ought to be.
Sounds good to me. What do other people think?
Is m.d.planning a good place for the remainder of discussion that goes
on on drivers, modulo partner-relations (separate list).
w.r.t partner relations, given what I've seen there so far, seems it
should consist of platform-leads + owners of likely affected fe modules
(which is similar to drivers today). Is that a reasonable assertion?
-Ben
Ben Goodger
> What's important about the drivers discussion is IMHO not a question of
> mailing lists, but power: who has the power to make decisions about
> Gecko --- to cut the endless threads and decide, for example, whether or
> not a module is part of "official Gecko", or whether a module owner has
> gone off the rails. We need to know who this group is. The group needs
> a name. If more than one person, it needs a forum for private discussion.
I think when you do that (have private lists), you need to be very clear
about what goes on there. For instance, I think there should be zero
technical discussion in such places. Otherwise the technical process
goes back to feeling mysterious and arbitrary to everyone else.
-Ben
Robert O'Callahan
> Benjamin Smedberg wrote:
>> I would personally prefer to deprecate the "gecko" name as vague, and
>> go with the "mozilla platform" or "mozilla toolkit". My preferred
>> group would be m.d.platform. Leave m.d.planning for
>> scheduling/releasing/meta-discussion issues, which really seems where
>> this discussion ought to be.
>
> Sounds good to me. What do other people think?
Yes, I like it.
> w.r.t partner relations, given what I've seen there so far, seems it
> should consist of platform-leads + owners of likely affected fe modules
> (which is similar to drivers today). Is that a reasonable assertion?
I think so.
Rob
Darin Fisher
I'd prefer "mozilla platform" as "toolkit" already means
mozilla/toolkit. To keep things clear, let "mozilla platform" be
inclusive of the "toolkit", "gecko", "necko", etc.
-Darin
Robert O'Callahan
I think not. Flash receives timer events from the system.
If we ran Flash in another process, we could pause the process (well on
Linux we could) but that would have bad side effects when we unpaused it.
Rob
Robert O'Callahan
> Perhaps what is needed is a group of "platform drivers" who will
> be responsible for making the final decision on issues concerning the
> direction of the Mozilla platform. In my opinion, this group should consist of
> the owners for the modules that make up the Mozilla platform.
That sounds good but I'm not 100% convinced yet.
It's an unfortunate fact that platform leadership sometimes requires
confidential discussions. Therefore platform leaders need to be trusted
to keep their mouths shut. This is not necessarily a requirement for
module ownership.
In the past we've had module owners who were technically sound but
really hard to work with. I'm not sure we want them as platform leaders.
(You might argue that they shouldn't be module owners but the fact is
that with poorly owned but vital code we sometimes have no choice.) I'd
hate to get into a situation where platform-leads is "all platform
module owners except for X and Y because they're annoying". It would be
much easier to be more selective at the outset.
I'm also concerned that the set of module owners may be too large to be
credible as leadership. Though once you weed out the inactive/legacy
module owners, and throw in non-Gecko module owners, I'm not real sure
who's currently in this group.
Another fact is that Firefox needs --- and deserves --- large input into
platform decisionmaking. There are probably other stakeholders who want
input. Maybe this isn't a concern as long as Firefox developers can hit
platform developer cubicle neighbours with sticks.
Rob
Ben Goodger
> It's an unfortunate fact that platform leadership sometimes requires
> confidential discussions.
Are these ever technical?
Or focused on process-related issues relating to modules within the
"platform" umbrella?
As far as app needs, like Firefox, I am happy communicating ideas and
questions about things that I might personally need (not speaking for
any other Fx contributor here) through a platform newsgroup. Platform
folk can use their best judgement as to whether or not the idea is
possible (at all, in the time frame of near-term app releases).
-Ben
Robert O'Callahan
> Are these ever technical?
Historically, I don't know, but it's hard to promise that they will
never be technical. "Spec XYZ sucks and these guys are idiots" is to
some extent a technical discussion that you might not want to have in
public.
Rob
Brendan Eich
> Brendan Eich wrote:
>
>> Where's the wiki interface to that page? :-P.
>
>
> https://doctor.mozilla.org/?file=mozilla-org/html/about/drivers.html
>
> :-P
Doesn't work. Did we not turn on ssh and turn off pserver for the
website? I think we must have, cuz of CVS pserver insecurity. I do not
see how doctor can work nowadays, if os.
/be
Boris Zbarsky
> Doesn't work. Did we not turn on ssh and turn off pserver for the
> website? I think we must have, cuz of CVS pserver insecurity.
I used doctor about 3 days ago to edit some docs, so if we haven't changed it
since then it works.
-Boris
Christian Biesinger
> Doesn't work.
It works, I used it the other day, and that was after the SSH switch.
> Did we not turn on ssh and turn off pserver for the
> website? I think we must have, cuz of CVS pserver insecurity. I do not
> see how doctor can work nowadays, if os.
My guess is that pserver is only enabled from doctor's host. But I don't
actually know if that's the case...
Ian Hickson
> >
> > https://doctor.mozilla.org/?file=mozilla-org/html/about/drivers.html
>
> Doesn't work. Did we not turn on ssh and turn off pserver for the
> website? I think we must have, cuz of CVS pserver insecurity. I do not
> see how doctor can work nowadays, if os.
Doctor works fine, it's how I update the XBL2 spec.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Ben Goodger
What is the effect of this? That you decide not to implement something?
Don't you need to eventually state your conclusions in a "politically
correct" way anyway, to answer questions from people? Wouldn't it be
easier to refer them to a thread where the issue was discussed? The
inquirer can then either add something of value or be quiet ;-)
Don't get me wrong, I truly appreciate the need to rant and rave. Anyone
who knows me knows this ;-) I've spent a lot of time being told that
this isn't appropriate on discussion lists though, so try and keep it to
the people sitting around me ;-)
-Ben
Ben Goodger
> What is the effect of this? That you decide not to implement something?
> Don't you need to eventually state your conclusions in a "politically
> correct" way anyway, to answer questions from people? Wouldn't it be
> easier to refer them to a thread where the issue was discussed? The
> inquirer can then either add something of value or be quiet ;-)
>
> Don't get me wrong, I truly appreciate the need to rant and rave. Anyone
> who knows me knows this ;-) I've spent a lot of time being told that
> this isn't appropriate on discussion lists though, so try and keep it to
> the people sitting around me ;-)
I should point out that I'm not telling any particular group of folk
what they should do.
I have just noticed that in general with the Mozilla project there are
many questions that are worth asking that never get asked because I
don't think contributors do a good enough job of keeping track of what's
going on in other parts of the world (I'm as guilty of this as anyone
else). What I and others are trying to figure out how here is how to
make that easier. And we're trying to do that by asking questions that
don't seem to have been asked before (or if they were, the answers were
forgotten).
What I've learned: any decision you make you will eventually have to
justify.
-Ben
Robert O'Callahan
> Robert O'Callahan wrote:
>> never be technical. "Spec XYZ sucks and these guys are idiots" is to
>> some extent a technical discussion that you might not want to have in
>> public.
>
> What is the effect of this? That you decide not to implement something?
We may refuse to accept a contribution, for example, or refuse to turn
it on by default.
> Don't you need to eventually state your conclusions in a "politically
> correct" way anyway, to answer questions from people?
Yes.
> Wouldn't it be
> easier to refer them to a thread where the issue was discussed?
Easier, yes. More productive, not necessarily. We have had situations
where someone is making a valuable contribution in some area, or at
least perceived as valuable by some subset of users, and we want them to
continue to contribute, so we don't want to alienate them unnecessarily.
In some cases people making proposals may want their proposal to never
become public if it is rejected.
Yes we want everything to be in the open as much as possible. It just
won't always be the right thing to do.
Rob
Jon Smirl
Take LKML (Linux Kernel Mailing List) for an example. All changes to
the kernel big or small go through that list. You can't bypass it
except for security fixes. All architecture changes are discussed on
LKML. If you want to get your code into the kernel it has to pass
though LKML no matter who you are and that includes Linus.
LKML does not differentiate between individuals and corporations,
everyone is treated as an individual. The list has 5,000 subscribers
spread over almost every time zone. People rant and rave on it all the
time. Groups get mad at each other and sometimes take all their
marbles and go home. Look at the abuse Hans Reiser gets on LKML. But
LKML still works and everything is open.
Is there something different about Mozilla that prevents the LKML
model from working?
--
Jon Smirl
jons...@gmail.com
Ian Hickson
>
> Robert O'Callahan wrote:
> >
> > never be technical. "Spec XYZ sucks and these guys are idiots" is to
> > some extent a technical discussion that you might not want to have in
> > public.
>
> What is the effect of this? That you decide not to implement something?
> Don't you need to eventually state your conclusions in a "politically
> correct" way anyway, to answer questions from people? Wouldn't it be
> easier to refer them to a thread where the issue was discussed? The
> inquirer can then either add something of value or be quiet ;-)
I'd recommend actually having the "spec XYZ sucks and these guys are
idiots" discussions in public. This would have two effects:
1. It would sharpen the arguments to technical reasons why the specs
suck, and
2. It would give feedback to those spec authors, leading to them making
their spec better.
I've had behind-closed-doors discussions with at least four independent
browser vendors about the fact that XHTML2 sucks. But if I try to tell the
ex-HTML working group this, they assume that I'm making stuff up and that
I'm just trying to waste their time. If you guys would only come out and
publically have these arguments, I could at least point said working group
to said discussions and show that I'm not lying. And then maybe they'd
actually improve their spec.
(XHTML2 is just one example. I've had similar discussions with the same
browser vendors about a number of other specs.)
Also, as a spec author myself, it worries me that you might be having
discussions in private about my own specs where you decide they suck and
that you're not going to implement them [1]. If you then have a
"politically correct" reason to not implement the spec, I won't know to
make the spec better, and I'll waste my time trying to solve your
politically correct reason instead of the real one.
[1] I don't mind so much that you think I'm an idiot. :-P
Boris Zbarsky
> Take LKML (Linux Kernel Mailing List) for an example.
What is the daily traffic volume on LKML, if I might ask?
-Boris
Brendan Eich
> I would prefer to have public pan-Gecko discussion in a newsgroup. It
> could even just go in mozilla.dev.planning. My general feeling is that
> these days it's better to err on the side of having fewer, more
> overloaded fora. I would use this group to announce upcoming major
> changes that will affect other applications and modules.
Agreed, especially on having too many overloaded fora. If the new
newsgroups aren't enough, I would be surprised. If we do add a few
more, ok -- provided they don't overlap anything significantly.
> What's important about the drivers discussion is IMHO not a question of
> mailing lists, but power: who has the power to make decisions about
> Gecko --- to cut the endless threads and decide, for example, whether or
> not a module is part of "official Gecko", or whether a module owner has
> gone off the rails. We need to know who this group is. The group needs
> a name. If more than one person, it needs a forum for private discussion.
Agreed so far.
> IMHO this group should be separated from release management. It's no
> trouble to call in module owners for help evaluating bugs as required.
Why is release management different in kind from planning release
milestones whose numbers show up in the user agent as the Gecko rv:? Or
different in kind from adjudicating code-level disputes that rise up
from module or super-module owners? The same whole-system thinking if
often required to make good decisions in all of these cases.
In particular, if bug-triage becomes more about consulting with module
owners, you can expect two things we have already seen, since the old
days of Netscape's "PDT", and still today on the branch releases:
* Failure to consult module owners or domain experts at all, or in time,
to make good triage decisions.
* Failure to consider the big picture, not just pan-codebase thinking
but what's-good-for-the-web, what's-good-for-end-users, etc.
Clearly you can skin these cats many ways, but I think keeping it simple
favors a small but living (as in, new people join, old ones retire --
working on this now!) group of experts who have demonstrated global and
even strategic thinking as well as local skills act as technical project
and meta-project management. That has been, for better or worse, the
role of drivers, although neither the name or the roster is necessary to
the idea.
What I'm disputing is the severance of broad, technical judgment for
release management from "pre-release" management. I'm not saying you
can't do this -- it tends to happen naturally due to specialization and
(frankly) the pain and tedium of triaging bugs and managing releases.
I'm saying that if you plan for this, you'll get worse releases, due to
the two bulleted items listed above.
/be
Brendan Eich
a public position on the spec and any implementation proposed for
Gecko or Mozilla.
It's bad when all the ranting happens in private and nothing emerges.
Not everything should be said right away in a broad, public forum.
That's bad technical politics, bad anthropology even. Sure, nothing but
silent conspiracies is bad too. And if the "P.C." summary is so vague
that you don't get needed feedback, that could suck.
But however much we bias toward being open and saying things in public,
there's a place for private communication. We're humans, humans do this
all the time, you can't stop it and you should not want to stamp it out
utterly. It ought to be put to work to improve the content of the
timely public messages. It has been, for me, working with others one on
one and in small groups, including drivers.
/be
Jon Smirl
300-400 messages per day. But I scan the subject lines and only read
about 20 messages per day. You get used to it after a while. When
people want to bring a message to your specific attention they will CC
you and make it land in your in-box.
Gmail is very effective for reading LKML with it's threads. It's not
the number of messages per day that matter; it is the number of new
threads that is more important. There are about 100 new threads per
day. I usually only read three or four of them.
A key attribute of the LKML model is the ability to have community
wide discussions on sensitive topics. For example support for DVD/CD
writers recently had a thread with a 1,000 messages. I would never
have guessed that that subject was so controversial.
I much prefer the single high volume list model over the current
Mozilla model. I am subscribed to about 30 Mozilla lists which average
about 20 messages per day across all of the lists put together. By
routing all technical discussions to a single list it would have more
activity and more readers. I often can't decide which Mozilla to use
when the subject spans multiple lists.
I have always been puzzled as to why there is such a low volume of
technical messages being posted about Mozilla. I've been attributing
this to most of the technical discussions happening in private.
--
Jon Smirl
jons...@gmail.com
Brendan Eich
> BTW, to clarify, I'm suggesting that platform-drivers@ or platform-leads@
> is a better way to go than gecko-leads@.
What about global-leads?
You can't say the dividing line between platform and non-platform is so
solid and understood, let alone uncontested, that some kind of mediation
and higher-level judging is not required now and then.
I also keep pointing out the milestone schedule. To be concrete, it
would be a loss if Firefox's development schedule were divorced
completely from Gecko's, such that the odds of Firefox shipping a
year-old Gecko were even higher than they are now.
Also, just having sub-leads get together in ad-hoc formations and settle
things loses. No consistency, no institutional memory (well, we lost
that a bit already, evidently), no clarity about how to appeal and where
appeals go next.
I'm looking for something that acknowledges or explicitly rejects the
global oversight that I claim is still needed, and that originally was
part of the motivation for drivers.
/be
Jon Smirl
300-400 messages per day. But I scan the subject lines and only read
Brendan Eich
> Benjamin Smedberg wrote:
>
>> I would personally prefer to deprecate the "gecko" name as vague, and
>> go with the "mozilla platform" or "mozilla toolkit". My preferred
>> group would be m.d.platform. Leave m.d.planning for
>> scheduling/releasing/meta-discussion issues, which really seems where
>> this discussion ought to be.
>
>
> Sounds good to me. What do other people think?
>
> Is m.d.planning a good place for the remainder of discussion that goes
> on on drivers, modulo partner-relations (separate list).
This sounds good to me, but roc's point about power remains. Who ends
the threads? Well, they can go on forever, but who exactly makes the
hard calls that affect global resources such as the milestone schedule,
the branching plan, what's in Gecko (not just for gecko-leads to decide
-- oops, mozilla-platform-leads ;-), etc.
> w.r.t partner relations, given what I've seen there so far, seems it
> should consist of platform-leads + owners of likely affected fe modules
> (which is similar to drivers today). Is that a reasonable assertion?
This is like drivers, but it also decides global stuff, it does not just
deal with partners.
I keep saying "global" because it seems to be lost in the old or new
sub-global, if not local, modules and lists. We can decide thorny
global issues as a group, looking for consensus, running with it when it
emerges, but in my experience you need something stronger: leadership in
both the negative ("no, go away or try again") and positive ("let's take
that next hill!") senses.
/be
Brendan Eich
> I think when you do that (have private lists), you need to be very clear
> about what goes on there. For instance, I think there should be zero
> technical discussion in such places. Otherwise the technical process
> goes back to feeling mysterious and arbitrary to everyone else.
Not everything is a clear-cut technical or non-technical discussion.
Eventually things may shake out along those lines. Or they may remain
entangled because of the human element (this implementation is the only
one, and the implementor disagrees on some fundamental values or beliefs
about what's good for the web, what is likely next year to happen, and
the like).
But you're right that it's a fine line, and most stuff needs to be cast
in technical terms, and in public, quickly. As I wrote to Hixie,
though, that doesn't always emerge instantly, or even within a few days.
If there are no private groups, there will still be private IMs, hallway
conversations, etc. These too need to be captured in public, archived
threads or docs. But they don't need to be banned.
Part of this is just rehearsing. Most theater companies don't rehearse
in public. You only get so many chances to fret and strut your hour on
the stage of others' attentions.
/be
Ben Goodger
> Not everything should be said right away in a broad, public forum.
> That's bad technical politics, bad anthropology even. Sure, nothing but
> silent conspiracies is bad too. And if the "P.C." summary is so vague
> that you don't get needed feedback, that could suck.
It could, but will it? I never said be vague, I said don't call people
"idiots". Is the only way you can develop an idea by calling people names?
What's worse is having a closed decision making process where the
reasons and results never filter to the public because:
- no one knows whose job it is to report this information to the public
- no one bothers, because the issue is "closed" and they can get on with
implementing or not implementing.
- if it is filtered to the public, everyone involved in the decision
making process considers the issue "closed" and thoughtful and
potentially responses are never taken into consideration.
Each of the examples I listed above has been a problem that has affected
one Mozilla group or another. I think that's part of the reason we're in
this situation.
-Ben
Brendan Eich
> Brendan Eich wrote:
>
>> Not everything should be said right away in a broad, public forum.
>> That's bad technical politics, bad anthropology even. Sure, nothing
>> but silent conspiracies is bad too. And if the "P.C." summary is so
>> vague that you don't get needed feedback, that could suck.
>
>
> It could, but will it? I never said be vague, I said don't call people
> "idiots". Is the only way you can develop an idea by calling people names?
Hey, it wasn't my example -- it was roc's. But, even if as you said
elsewhere, all such reactions are confined to one's nearby cube
neigbors, there may still be value in getting a smaller audience of
trusted advisors to review something before you launch it at the world.
That's all I was getting at.
> What's worse is having a closed decision making process
I was not talking about closed decision-making, but narrower rather than
wider circles of thinking out loud, discussing, getting a coherent idea
together as a proposal.
Almost everything is a proposal around here. Unless it's a CVS commit,
and even then.
> where the
> reasons and results never filter to the public because:
>
> - no one knows whose job it is to report this information to the public
> - no one bothers, because the issue is "closed" and they can get on with
> implementing or not implementing.
> - if it is filtered to the public, everyone involved in the decision
> making process considers the issue "closed" and thoughtful and
> potentially responses are never taken into consideration.
>
> Each of the examples I listed above has been a problem that has affected
> one Mozilla group or another. I think that's part of the reason we're in
> this situation.
You're right, for sure. My post was against the "let it all hang out,
all the time" counter-reaction. Let's synthesize something more like
the all-open-all-the-time, but with some recognition, whether it is for
cube-neighbors, IM and IRC, or some ad-hoc mailing-a-draft-around, for
the value of rehearsing proposals and drafting better public statements.
/be
Darin Fisher
> In the past we've had module owners who were technically sound but
> really hard to work with. I'm not sure we want them as platform leaders.
> (You might argue that they shouldn't be module owners but the fact is
> that with poorly owned but vital code we sometimes have no choice.) I'd
> hate to get into a situation where platform-leads is "all platform
> module owners except for X and Y because they're annoying". It would be
> much easier to be more selective at the outset.
>
> I'm also concerned that the set of module owners may be too large to be
> credible as leadership. Though once you weed out the inactive/legacy
> module owners, and throw in non-Gecko module owners, I'm not real sure
> who's currently in this group.
>
> Another fact is that Firefox needs --- and deserves --- large input into
> platform decisionmaking. There are probably other stakeholders who want
> input. Maybe this isn't a concern as long as Firefox developers can hit
> platform developer cubicle neighbours with sticks.
I think we need to think about the mozilla platform as a product. Our
customers are applications like Firefox and Thunderbird. As a
producer of a product, we naturally have to be concerned about the
interests of our customers :-)
I see your point about building platform-leads team from module
owners. I suggested it as an unbiased way of building such a group.
Moreover, since module owners technically have control over their
modules, what good would a platform-leads group be if it did not
include all of the module owners? It would be powerless, wouldn't it?
Maybe there is a better way?
Maybe the existing "modules" are not defined properly for this to work.
One of my concerns with drivers and super-reviewers is that they are
obviously stale lists of contributors, and there apparently isn't
enough self-policing to clean either up. I wouldn't want us to repeat
that with platform-leads. The list of module owners, however, adjusts
itself a bit more organically, and that's nice for a project like
this. People, like bsmedberg, who take the "bull by the horns" become
module owners. We want to encourage that, and make it really obvious
how one goes from being a mere patch contributor to someone who helps
assert direction for the platform.
Moreover, if we have a team like platform-leads that is made up of
module owners, then we can give that team the responsibility of
including new people by delegating module ownership rights, granting
authority (power) if you will. This would require some sort of
consensus amongst members, similar to the process by which someone
becomes a super-reviewer.
But, maybe there is a better way to organize a group such as
platform-leads. Suggestions?
-Darin
Ian Hickson
>
> 300-400 messages per day.
Good lord.
> I have always been puzzled as to why there is such a low volume of
> technical messages being posted about Mozilla. I've been attributing
> this to most of the technical discussions happening in private.
It mostly happens on bugs.
Brendan Eich
> I think we need to think about the mozilla platform as a product. Our
> customers are applications like Firefox and Thunderbird. As a
> producer of a product, we naturally have to be concerned about the
> interests of our customers :-)
This is right on. But let's agree on customers too. They include not
only apps embedding Gecko, or to get with the mozilla-platform meme,
built on the platform. They include app-extension and web developers.
> One of my concerns with drivers and super-reviewers is that they are
> obviously stale lists of contributors,
Drivers is not stale, as implemented by a mailman list. It includes
ben, bsmedberg, mscott, dbaron, roc, bz, and other bigwigs.
Maybe it leaves out someone who wants to join. Ben did, and joined.
Who is next?
> and there apparently isn't
> enough self-policing to clean either up.
I am fighting with doctor and cvs auth right now to fix the crummy
website list. Just so you know.
Super-reviewers is less well-maintained, but it has also seen some
recent maintenance. As we agreed, though, code requiring sr is rarer
all the time.
> I wouldn't want us to repeat
> that with platform-leads. The list of module owners, however, adjusts
> itself a bit more organically,
Hah! Apart from module owners picking peers and sometimes successors,
it's all up to me and dbaron, using broken old despot.
I don't think it's that much better off than the other lists you
disparage, but that's not to say module ownership is meaningless (any
more than drivers are meaningless).
> and that's nice for a project like
> this. People, like bsmedberg, who take the "bull by the horns" become
> module owners.
And drivers, when they are nominated and consent, or they volunteer.
> We want to encourage that, and make it really obvious
> how one goes from being a mere patch contributor to someone who helps
> assert direction for the platform.
Agreed. I'm not picking nits above, at least I don't think I am. There
seems to me to be some special pleading going on for module ownership,
over against driver-ship. Active drivers actually are busting their
backsides on patch releases right now, just FYI. Consider dveditz, but
not just dveditz.
Again I'm not out to stop a better system from being formed, or some
essential feature being recovered (reform). But if you don't know or
(much) respect anything (however imperfect) in what drivers have done
historically or in recent weeks, I'm not sure I trust your new plan. It
could be great, but it would be even better if it adverted to relevant
Mozilla history and experience.
/be
Ben Goodger
> Darin Fisher wrote:
>
>> BTW, to clarify, I'm suggesting that platform-drivers@ or platform-leads@
>> is a better way to go than gecko-leads@.
>
> What about global-leads?
I don't think this is a good name for platform concerns, since it
implies ownership of other projects like Firefox, Tbird, Camino etc.
As an alias for a "staff@-like-but-more-contemporary-and-relevant"
collection of owners of sub-projects, global-leads@ sounds like an
interesting idea, but that's another discussion.
-Ben
Brendan Eich
> On Mon, 13 Mar 2006, Jon Smirl wrote:
>
>>300-400 messages per day.
>
>
> Good lord.
Yeah, I choked when I read that -- actually spat up in my mouth a little
;-).
>>I have always been puzzled as to why there is such a low volume of
>>technical messages being posted about Mozilla. I've been attributing
>>this to most of the technical discussions happening in private.
>
>
> It mostly happens on bugs.
Right. Maybe not the best fora for others to read, but still pretty
close to the action, with the right cc: lists over time.
I would hate to see us use anything like the LKML list approach.
/be
Ian Hickson
>
> Drivers is not stale, as implemented by a mailman list. It includes
> ben, bsmedberg, mscott, dbaron, roc, bz, and other bigwigs.
>
> Maybe it leaves out someone who wants to join. Ben did, and joined. Who
> is next?
Can I join?
Brendan Eich
> Brendan Eich wrote:
>
>> Darin Fisher wrote:
>>
>>> BTW, to clarify, I'm suggesting that platform-drivers@ or
>>> platform-leads@
>>> is a better way to go than gecko-leads@.
>>
>>
>> What about global-leads?
>
>
> I don't think this is a good name for platform concerns, since it
> implies ownership of other projects like Firefox, Tbird, Camino etc.
You misunderstood -- I was not trying to rename darin's platform-leads
name, I was asking what the name of the other list, the one like drivers
as it was originally constituted, and still tries to act in many ways,
should be. The global-oversight list that I haven't heard about yet.
> As an alias for a "staff@-like-but-more-contemporary-and-relevant"
> collection of owners of sub-projects, global-leads@ sounds like an
> interesting idea, but that's another discussion.
That's your other discussion. Since I'm not objecting to platform-leads
but asking about the next level up, it's my discussion.
Since we are being open here in communicating, sharing one big thread
with an unrelated Subject, why reject my discussion topic (misunderstood
or not)? It seems critical to me that we have this
"drivers@-like-but-more-contemporary-and-relevant" global-leads
discussion, since I claim based on concrete experience that platform-
and app-leads cannot consistently and independently solve critical
problems inherent in our shared resources.
/be
Brendan Eich
> On Mon, 13 Mar 2006, Brendan Eich wrote:
>
>>Drivers is not stale, as implemented by a mailman list. It includes
>>ben, bsmedberg, mscott, dbaron, roc, bz, and other bigwigs.
>>
>>Maybe it leaves out someone who wants to join. Ben did, and joined. Who
>>is next?
>
>
> Can I join?
Sure, I'll nominate you. If no one rejects you as a bad actor, you're
in. Are you sure you have the time? I'm in favor, but I was slightly
suspicious that you were kidding, or testing, or something like that.
/be
Darin Fisher
> Darin Fisher wrote:
>
> > BTW, to clarify, I'm suggesting that platform-drivers@ or platform-leads@
> > is a better way to go than gecko-leads@.
>
> What about global-leads?
>
> You can't say the dividing line between platform and non-platform is so
> solid and understood, let alone uncontested, that some kind of mediation
> and higher-level judging is not required now and then.
To me, global-leads sounds like a group of folks who would have say
over products like Firefox or Camino. That doesn't seem to be what we
need. We have solid leadership for those products. What I think we
need to do is to formalize the leadership structure around the Mozilla
Platform product. In light of developments such a xulrunner/libxul,
the line between the platform and the application is indeed becoming
very well defined.
Back when drivers was created, it was responsible for doing a lot of
things, and it was clearly responsible for the Mozilla Suite. But,
Firefox, Thunderbird, and even Camino were created outside the purview
of drivers. And, I believe that's fine. They are separate products
with separate driving forces.
The issues you raised about MNG, SVG1.2, and XForms are the domain of
the Mozilla Platform. It might make sense for Firefox to request a
platform feature (e.g., better content sniffing APIs), but that can
happen on dev.tech.{blah}. Any debates over such a feature would
naturally be resolved by the platform leads (since they control the
product in question). That's what happens in an ad-hoc fashion today,
and doesn't that make sense?
> I also keep pointing out the milestone schedule. To be concrete, it
> would be a loss if Firefox's development schedule were divorced
> completely from Gecko's, such that the odds of Firefox shipping a
> year-old Gecko were even higher than they are now.
I don't understand. Platform leaders should be involved in the
Firefox product meetings if they wish to affect the Firefox product.
That is happening today, and maybe it should happen to a greater
extent. Perhaps you should attend? ;-)
> Also, just having sub-leads get together in ad-hoc formations and settle
> things loses. No consistency, no institutional memory (well, we lost
> that a bit already, evidently), no clarity about how to appeal and where
> appeals go next.
Can't we create some rules for these things -- a charter? We have
rules for how people become super-reviewers. As I said in response to
Roc, the idea of building platform-leads from module owners was a
suggestion I made because it felt like the most unbiased way to create
such a group. You take the set of active leaders and have them work
together when necessary to settle issues such as whether or not some
feature belongs in the platform.
I'm not sure I fully understand the mistrust of module owners, by the
way. Afterall, they are given quite a bit of power in our
environment, and so it is in our best interest to ensure that module
owners are doing their job well. A group of platform leads ought to
be responsible for policing such things, for granting module ownership
rights, and for making adjustments where warranted.
> I'm looking for something that acknowledges or explicitly rejects the
> global oversight that I claim is still needed, and that originally was
> part of the motivation for drivers.
Again, the Mozilla Platform should be treated like a product that we
are building for our customers: Firefox, Thunderbird, Camino, etc.
If we take this view point, then we don't need to place someone (or
some group) above all to make decisions from the top.
I assert that we really don't have global oversight today, and that's
okay. It is valuable to think globally, but actually making an impact
globally requires one to be involved in both the Mozilla Platform
development process (or product planning) as well as the [fill in the
blank] application development process (or product planning). I think
this is fine and as it should be.
Let's take an example: XULRunner. The decision to build Firefox on
top of XULRunner should be a decision that the Firefox product team
makes because they feel that it is the best thing for Firefox. It is
the job of the Mozilla Platform team to convince the Firefox team that
XULRunner is the best choice for Firefox if indeed it is. You see
where I'm going with this?
-Darin
Brendan Eich
> Christian Biesinger wrote:
>
>> Brendan Eich wrote:
>>
>>> Where's the wiki interface to that page? :-P.
>>
>>
>>
>> https://doctor.mozilla.org/?file=mozilla-org/html/about/drivers.html
>>
>> :-P
>
>
>
> Doesn't work. Did we not turn on ssh and turn off pserver for the
> website? I think we must have, cuz of CVS pserver insecurity. I do not
> see how doctor can work nowadays, if os.
Ok, I needed n00b help from justdave (thanks!), but it works now. I've
udpated the drivers list on that page.
/be
Robert O'Callahan
> I'd recommend actually having the "spec XYZ sucks and these guys are
> idiots" discussions in public. This would have two effects:
I'm actually not aware of any situation where anyone's privately decided
that a spec sucks and failed to inform the public :-). So my example
wasn't very good.
I was thinking of MNG, where there was a good deal of public discussion
over problems with the spec, but it had to be raised again when we
retreated into a private discussion (the retreat being partly due to
sheer signal/noise issues, I think).
Rob
Jon Smirl
> On Mon, 13 Mar 2006, Jon Smirl wrote:
> >
> > 300-400 messages per day.
>
> Good lord.
It is not as bad as you think. People use mail filters on the messages
to sort them. You also get used to scanning the subject lines of the
new threads. I can monitor LKML in under 10 minutes per day. The three
Ruby lists combined are 400-500 messages per day.
These combined lists have a major value in the amount of cross
pollination that happens. Several times I have posted code and someone
from India or China will fix all of the i18n problems in it and have a
patch in my mail when I wake up. I incorporate those fixes and repost
to the list until everything is right. At that point a lieutenant
(usually GregKH in my area) will pull my code into one of his trees.
After a while Greg will then push the combined patches to Linus. Linus
then commits them to the main kernel tree. In general (there are
backup people now) Linus is the only person commiting to the main
kernel tree.
> > I have always been puzzled as to why there is such a low volume of
> > technical messages being posted about Mozilla. I've been attributing
> > this to most of the technical discussions happening in private.
>
> It mostly happens on bugs.
Bugs don't end up in Google. That makes it hard to find the discussion
unless you specifically start searching in bugzilla.
Could bugzilla be modified to leave a static copy of each bug page in
a public directory? There are 350K bugs in the db but they are less
than 1K per page. That's only 350MB of disk space. Google would index
this and make it searchable.
LKML archives are vaulable as an educational tool. People read them to
understand how things got the where they are. I have received mail
referencing posts of mine that were several years old.
--
Jon Smirl
jons...@gmail.com
Jon Smirl
Ian Hickson
I wasn't kidding or testing, no.
I would not have the time to do any "work", but I would have the time to
observe and contribute opinions where relevant. I am especially interested
in seeing the technical discussions regarding specifications that roc
alluded to earlier today.
Robert O'Callahan
> It could, but will it? I never said be vague, I said don't call people
> "idiots". Is the only way you can develop an idea by calling people names?
Sometimes you have to make judgments that people will interpret as
calling them names.
Rob
Darin Fisher
>
> > I think we need to think about the mozilla platform as a product. Our
> > customers are applications like Firefox and Thunderbird. As a
> > producer of a product, we naturally have to be concerned about the
> > interests of our customers :-)
>
> This is right on. But let's agree on customers too. They include not
> only apps embedding Gecko, or to get with the mozilla-platform meme,
> built on the platform. They include app-extension and web developers.
Agreed on web developers. As for app-extensions... it depends ;-)
Some of those extensions are really platform extensions, and some of
them are purely application-level extensions. Of course, many are a
mix.
> > One of my concerns with drivers and super-reviewers is that they are
> > obviously stale lists of contributors,
>
> Drivers is not stale, as implemented by a mailman list. It includes
> ben, bsmedberg, mscott, dbaron, roc, bz, and other bigwigs.
Ahem... see website please! :-)
http://www.mozilla.org/about/drivers
OK... I see that you are doing so... awesome!
> Maybe it leaves out someone who wants to join. Ben did, and joined.
> Who is next?
I'm of course interested, but that's not the point. It would help me
personally if I was able to see things from the inside and I would be
having this conversation if I didn't want to contribute, but that
hardly solves the problem ;-)
> > I wouldn't want us to repeat
> > that with platform-leads. The list of module owners, however, adjusts
> > itself a bit more organically,
>
> Hah! Apart from module owners picking peers and sometimes successors,
> it's all up to me and dbaron, using broken old despot.
>
> I don't think it's that much better off than the other lists you
> disparage, but that's not to say module ownership is meaningless (any
> more than drivers are meaningless).
"disparage" ... perhaps I'm being to rough in trying to motivate change?
In my opinion, it should be up to the platforms leads to select and
manage module owners for modules that make up the platform. Clearly,
you and dbaron are platform leaders, so this isn't a big problem ;-)
> > We want to encourage that, and make it really obvious
> > how one goes from being a mere patch contributor to someone who helps
> > assert direction for the platform.
>
> Agreed. I'm not picking nits above, at least I don't think I am. There
> seems to me to be some special pleading going on for module ownership,
> over against driver-ship. Active drivers actually are busting their
> backsides on patch releases right now, just FYI. Consider dveditz, but
> not just dveditz.
dveditz is doing a great job. I was happy to hear that he would be
leading the next dot-release of Firefox 1.5. This brings up the issue
of a sustaining team for Firefox releases. That is an interesting
subject because it generally focuses on security fixes and crash fixes
that are often, but not always, in the platform space. It seems to me
that the Firefox product team and the Platform product team should
work together to select a team that will be responsible for driving
dot-releases. Having the responsibility for dot-releases placed on
drivers when they were not leading the primary product release (e.g.,
FF 1.5) seems a bit non-ideal to me.
> Again I'm not out to stop a better system from being formed, or some
> essential feature being recovered (reform). But if you don't know or
> (much) respect anything (however imperfect) in what drivers have done
> historically or in recent weeks, I'm not sure I trust your new plan. It
> could be great, but it would be even better if it adverted to relevant
> Mozilla history and experience.
Come on now, if drivers were a transparent organization then I'd know
what they do! Unfortunately, I'm left guessing. I know what the
Firefox product team does, and I know what module owners do. Perhaps
I'm just ill-informed afterall?
-Darin
Brendan Eich
arrange things like bfcache's landing, a bunch of negotiation about SVG
that affects Firefox and Gecko together, and thankless security-bug
hell-holes that dveditz and I (at least) have personally spent too much
time in.
I also think you overstate the ability of any one projects' leads group
to negotiate with the platform-leads to get the right fixes or features.
Again I cite the tabbed-browsing (single window) failed exercise from
near the end of 1.5 as one example. There are others. And the shoe can
be on both feet here -- I'm not blaming either app- or platform-leaders
in that example.
Sure, with the right super-group of platform- and app-leads, everything
can be worked out. Why not convene that group as a permanent entity
instead of ad-hoc multiple groups, recognize it as the successor to
drivers, and charter it with similar authority? As roc said, the power
question remains. Or do you suppose, in the worst case, that Firefox
leads should fiddle with Gecko config and UA string content?
(Inviting me to attend Firefox product meetings is a cheap shot, but I
suppose that if I don't, anything I say about Firefox will be discounted
:-(.)
We do have global oversight today, not only from drivers but from anyone
with the eyes to see far. That's how bsmedberg, for example, became a
driver. If you insist on him either (a) staying a platform-lead; or (b)
joining as many clubs as will have him as a member in order to have
decisive authority over (in the worst case) a zero-sum global dilemma,
then I think you are making it harder, not easier, for people to help
ensure better global outcomes.
/be
Ben Goodger
> Since we are being open here in communicating, sharing one big thread
> with an unrelated Subject, why reject my discussion topic (misunderstood
> or not)? It seems critical to me that we have this
> "drivers@-like-but-more-contemporary-and-relevant" global-leads
> discussion, since I claim based on concrete experience that platform-
> and app-leads cannot consistently and independently solve critical
> problems inherent in our shared resources.
What problems does having this group solve? Is it more of a 'what bugs
get approved for which release' sort of thing?
-Ben
Brendan Eich
> I would not have the time to do any "work", but I would have the time to
> observe and contribute opinions where relevant. I am especially interested
> in seeing the technical discussions regarding specifications that roc
> alluded to earlier today.
Ok then -- that's easier. The dri...@mozilla.org mailing list already
has observer-members, people who are watching but not acting with driver
authority.
/be
Robert O'Callahan
> Why is release management different in kind from planning release
> milestones whose numbers show up in the user agent as the Gecko rv:?
I think release management is generally more localized.
When we decide to move all rendering to cairo, or simplify the native
widget hierarchy to eliminate child widgets, those are technical
decisions that will impact a lot of people and have a major and lasting
impact on the code, and on product schedules. These are the sort of
decisions I'd like to know about and have a chance to provide feedback
on even when they're not in my immediate zone of interest.
Deciding whether or not to accept certain bug fixes for a release
usually has much less lasting impact. These are patches that we have
already landed on trunk and agreed to ship eventually; the only question
is whether they make release N or N+1, which is a question of balancing
risks. If there is wide-ranging impact, developers should already be
aware of it, because it's already happened on trunk. Yes, there are
cases when a branch landing needs to trigger other people into action,
but I don't think those cases demand release management and longer-range
planning share a single group.
Rob
Ben Goodger
> I assert that we really don't have global oversight today, and that's
> okay.
For a concrete example,
For the RSS feature of Firefox 2.0, I was interested in content type
handling/sniffing. I talked to biesi, bz and darin about the sort of
things I needed. This happened on IRC (could easily have happened on a
platform list - just wanted to give a sense of the interactions). The
platform folk determined whether a solution was possible, what needed to
be done on the platform, etc. Now there are bugs and patches and fixes
and a happy applications customer. No overarching coordination from a
central org.
-Ben
L. David Baron
> dot-releases. Having the responsibility for dot-releases placed on
> drivers when they were not leading the primary product release (e.g.,
> FF 1.5) seems a bit non-ideal to me.
I don't think you're going to get the same group of people interested in
managing both types of releases.
It would be good to get a little more input across the two types of
release managers, though: more attention to security bugs in the runup
to a major release, and more attention to the other effects of fixes
taken in the current and previous security releases (so we fix
regressions from security fixes so product quality doesn't decline
progressively with each security release)
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation