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 driv...@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-fire...@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,
driv...@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, mozilla...@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
security-gr...@mozilla.org who are in similar positions at downstream
distributor companies.

On 3/9/06, Brendan Eich <bren...@meer.net> wrote:

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! :-/

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?

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.

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.

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

[Trying to set reply-to/followup-to again, to dev-general.   Also
trimming the cc's to the list gateways. /be]

Yup.

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.

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.

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).

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.

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.

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.

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.

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.

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?

Drivers do this and have historically done this.  Same wheel.

You don't want bugzilla-request-daemon mail spamming bonecho.  You do
not want all bugs discussed in ...

read more »

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.

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

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.

Yes.  We're old, and our policy wonking fell behind our hacking and
struggling for viable organizational structure.

As I said, we can change names such as "drivers".  The argument was
about substance, not surface.

I agree.  Concrete proposals would help.  Please make some, I'm not
going to shoot anything down that preserved needed substance.

/be

Separate post, separate (but linked) topic.

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

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-relati...@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

If bz is in drivers perhaps someone should update
<http://www.mozilla.org/about/drivers>.
   Peter.

Brendan Eich schrieb:

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).

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

On 3/9/06, Brendan Eich <bren...@meer.net> wrote:

I just replied to both lists last time :-/  Gmail suggested that, and
I didn't look closely at the message headers.

Good.

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.

Agreed 100%.

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.)

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.

Good, we see eye-to-eye here :)

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.

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-le...@mozilla.org) and a corresponding private mailing
list (gecko-leads-priv...@mozilla.org) for those times when
security-sensitive matters need to be discussed.  Let
gecko-le...@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-le...@mozilla.org mailing list.

Let me know if you think I'm wildly off-track here.

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.

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.

gecko-leads!

bonecho!

Agreed.  I'm looking for organization too.  My last email was light on
...

read more »

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.

Yes, well, that too :)

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?

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

On 3/10/06, Brendan Eich <bren...@meer.net> 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
(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
jonsm...@gmail.com

On 3/10/06, Jon Smirl <jonsm...@gmail.com> wrote:

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

To be fair, those docs have always been pretty rusty.

Browse through www.apache.org or subversion.tigris.org for comparison ;-)

-Ben

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...

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

On 3/10/06, Darin Fisher <dar...@gmail.com> wrote:

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
jonsm...@gmail.com

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

Actually, we'd kinda like to get rid of XTF... ;)

Depends on how slow do you want your SVG to be.  XTF is not very performant, imo.

Generality and performance often conflict.....  That's one reason some of Gecko
is not more general and modular.  :(

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

On 3/10/06, Boris Zbarsky <bzbar...@mit.edu> wrote:

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
jonsm...@gmail.com

On 3/10/06, Ben Goodger <bengood...@gmail.com> wrote:

Hey, that sounds even better to me.  So, just a gecko-le...@mozilla.org then :-)

-Darin

Some people have.  That's not relevant here, though; see below.

Sure.  If you go off on a branch for a year or so merging is hard when you
decide to finally do it.

Except Daniel has commit access to mozilla.org CVS.  He's one of the Editor
module owners, in fact.

Sure, but that's not what happened here.

Yep.  Given the above, I repeat my claim that the issue with NVU is not a
technological issue.

-Boris

Where's the wiki interface to that page? :-P.

/be

Yeah, www.mozilla.org started rusting fast right about when jwz quit.

/be

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

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.

We hear nothing from Flock.  Our planning docs are all wiki'd.  They are
welcome to participate.

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