Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Mozilla 2 repository migration dirlist

41 views
Skip to first unread message

bre...@mozilla.org

unread,
Mar 28, 2007, 12:40:12 AM3/28/07
to benj...@smedbergs.us, j...@mozilla.org
Here is the minimal list of files and directories, including their
subdirectories in the case of directories, from under
cvs.mozilla.org's mozilla top-level directory, that I propose we
migrate into the Mozilla 2 initial repository:

Makefile.in
LICENSE
LEGAL
README.txt
accessible
aclocal.m4
allmakefiles.sh
browser
build
caps
chrome
config
configure.in
client.mk
content
db
dbm
docshell
dom
editor
embedding
extensions/Makefile.in
extensions/access-builtin
extensions/auth
extensions/canvas3d
extensions/cck
extensions/cookie
extensions/datetime
extensions/finger
extensions/gnomevfs
extensions/inspector
extensions/java
extensions/jssh
extensions/layout-debug
extensions/metrics
extensions/negotiateauth
extensions/permissions
extensions/pref
extensions/python
extensions/reporter
extensions/spellcheck
extensions/universalchardet
gfx
intl
ipc
jpeg
js
layout
modules
netwerk
nsprpub
other-licenses
parser
plugin
profile
rdf
security
storage
sun-java
testing
themes
toolkit
tools
uriloader
view
webshell
widget
xpcom
xpfe
xpinstall
xulrunner

See http://wiki.mozilla.org/Mozilla2 for more. The initial repository
will be a Mercurial one, but don't panic. We need to get to work on
Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
repository solution to emerge. We'll start with hg, and reconsider bzr
if it speeds up enough. See preed's blog for why we can't use git or
other contenders and wannabes.

Also do not panic about the above list leaving out mail, mailnews,
composer, calendar, camino, etc. Mozilla 2 needs focus and the
repository can grow. Or, with better VCSes such as hg, we can have
several repositories. With better embedding APIs we won't want to
tightly couple source of a given XUL app to source of a given Gecko
back end file. But we will want to keep Firefox and XULRunner building
at all times. So the above list does include those two.

Comments welcome, but we are likely to create this soon. Useful
comments would be "don't forget xyzzy or you can't build foopy", not
"why aren't you importing electricalfire" or the like.

Thanks to Benjamin for help getting this list right (jst and pav too).

/be

Gijs Kruitbosch

unread,
Mar 28, 2007, 2:37:39 AM3/28/07
to bre...@mozilla.org, benj...@smedbergs.us, j...@mozilla.org
bre...@mozilla.org wrote:
> Here is the minimal list of files and directories, including their
> subdirectories in the case of directories, from under
> cvs.mozilla.org's mozilla top-level directory, that I propose we
> migrate into the Mozilla 2 initial repository:
>
> <snip>
> xpfe
> <snip>

>
> See http://wiki.mozilla.org/Mozilla2 for more. The initial repository
> will be a Mercurial one, but don't panic. We need to get to work on
> Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
> repository solution to emerge. We'll start with hg, and reconsider bzr
> if it speeds up enough. See preed's blog for why we can't use git or
> other contenders and wannabes.
>
> Also do not panic about the above list leaving out mail, mailnews,
> composer, calendar, camino, etc. Mozilla 2 needs focus and the
> repository can grow. Or, with better VCSes such as hg, we can have
> several repositories. With better embedding APIs we won't want to
> tightly couple source of a given XUL app to source of a given Gecko
> back end file. But we will want to keep Firefox and XULRunner building
> at all times. So the above list does include those two.
>
> Comments welcome, but we are likely to create this soon. Useful
> comments would be "don't forget xyzzy or you can't build foopy", not
> "why aren't you importing electricalfire" or the like.
>
> Thanks to Benjamin for help getting this list right (jst and pav too).
>
> /be
>

It's my understanding that xpfe is currently only used by the Suite, and
they're moving away from it. Could someone explain why it is in this
list, then? (My apologies for any ignorance demonstrated - I suppose I'm
just curious)

-- Gijs

Eli Friedman

unread,
Mar 28, 2007, 3:29:52 AM3/28/07
to
Gijs Kruitbosch wrote:
> It's my understanding that xpfe is currently only used by the Suite, and
> they're moving away from it. Could someone explain why it is in this
> list, then? (My apologies for any ignorance demonstrated - I suppose I'm
> just curious)
>
> -- Gijs

I believe Firefox still depends on some code in xpfe, including
xpfe/appshell.

-Eli

bre...@mozilla.org

unread,
Mar 28, 2007, 3:33:02 AM3/28/07
to
On Mar 27, 11:37 pm, Gijs Kruitbosch <gijskruitbo...@gmail.com> wrote:
> It's my understanding that xpfe is currently only used by the Suite, and
> they're moving away from it. Could someone explain why it is in this
> list, then? (My apologies for any ignorance demonstrated - I suppose I'm
> just curious)

(I replied via email to Gijs already, but for the record:)

xpfe is pulled and built when building Firefox, at least parts of it
are. We don't propose to "fix" this before starting the Mozilla 2
migration.

BTW, in case it's not clear from the wiki docs and my origina Mozilla
2 blog, we will of course use the new repository's better branching
and merging to automate merges from the 1.9 CVS trunk into the Hg
repo, probably nightly to a copy of the trunk. From that, we'll
maintain a branch that periodically, based on known-good 1.9 status,
merges 1.9 and Mozilla 2. As noted in my blog, we anticipate many
experimental branches (for Tamarin work, Oink/Elsa-based refactoring,
etc.) and related integration branches feeding back into the main
Mozilla 2 branch.

In the course of the next few months, we should also find it easier in
Hg to rename and remove things, including xpfe if we can (sun-java
too). So Gijs' point is well taken.

/be

Gervase Markham

unread,
Mar 28, 2007, 6:11:23 AM3/28/07
to
bre...@mozilla.org wrote:
> nsprpub

What are the plans for taking releases of NSPR and NSS, as they are
released by their respective teams? You probably don't want to just
import the trunk versions of these two directories.

> other-licenses

All of it? I think you could do without, at least, libart_lgpl and libical.

> security

Again, there are directories in here ("svrcore"?) which you may not need.

> tools

Is there not an unnecessary accidental forkage risk here? Yes, we can
merge stuff across, and perhaps the set of people working on stuff in
here is small enough that it won't matter, but it might make sense to
just keep these in one place or the other, as many aren't build
dependencies.

> widget

Again, all of them?

Hope those are useful comments.

Gerv

Neil

unread,
Mar 28, 2007, 6:33:55 AM3/28/07
to
Gervase Markham wrote:

> bre...@mozilla.org wrote:
>
>> widget
>
> Again, all of them?

Most of them, I would have thought... but under gfx you probably only
need cairo/thebes, right?

--
Warning: May contain traces of nuts.

T Rowley

unread,
Mar 28, 2007, 8:34:31 AM3/28/07
to
On 3/27/07 11:40 PM, bre...@mozilla.org wrote:
> See http://wiki.mozilla.org/Mozilla2 for more. The initial repository
> will be a Mercurial one, but don't panic. We need to get to work on
> Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
> repository solution to emerge. We'll start with hg, and reconsider bzr
> if it speeds up enough. See preed's blog for why we can't use git or
> other contenders and wannabes.

Who is going to be doing this work concurrent with 1.9? All the core
developers I'm aware of have their plates full getting 1.9 into
shippable form.

Benjamin Smedberg

unread,
Mar 28, 2007, 8:57:37 AM3/28/07
to
Gervase Markham wrote:

>> tools
>
> Is there not an unnecessary accidental forkage risk here? Yes, we can
> merge stuff across, and perhaps the set of people working on stuff in
> here is small enough that it won't matter, but it might make sense to
> just keep these in one place or the other, as many aren't build
> dependencies.

There will be no forking. The Hg repository will be periodically (at least
once a day) re-imported from CVS. Somebody from the mozilla2 team will do
merging if necessary.

--BDS

Benjamin Smedberg

unread,
Mar 28, 2007, 11:07:15 AM3/28/07
to
Gijs Kruitbosch wrote:

> It's my understanding that xpfe is currently only used by the Suite, and
> they're moving away from it. Could someone explain why it is in this
> list, then? (My apologies for any ignorance demonstrated - I suppose I'm
> just curious)

xpfe/ is a wasteland of code built by various apps. Some of it is in the
platform (xpfe/appshell), some of it is inconveniently shared between
firefox and seamonkey (xpfe/components/...). We are gradually working
towards moving everything out of xpfe/ to an appropriate module, but for the
time being it is needed.

--BDS

Benjamin Smedberg

unread,
Mar 28, 2007, 11:11:21 AM3/28/07
to
Gervase Markham wrote:

>> nsprpub
>
> What are the plans for taking releases of NSPR and NSS, as they are
> released by their respective teams? You probably don't want to just
> import the trunk versions of these two directories.

I'm not sure yet whether we'll be importing trunk or the client branch/tags
of these. And I do believe the goal is to have these in their own repository
at some point.

>> other-licenses
>
> All of it? I think you could do without, at least, libart_lgpl and libical.

I'll work on separating this out a bit more.

>> widget
>
> Again, all of them?

I don't see any need to be more granular. Obviously there is old/unsupported
code there, but it's inconsequential and can be remove later at our leisure.

--BDS

Robert Kaiser

unread,
Mar 28, 2007, 12:16:32 PM3/28/07
to
bre...@mozilla.org schrieb:

> See http://wiki.mozilla.org/Mozilla2 for more. The initial repository
> will be a Mercurial one, but don't panic. We need to get to work on
> Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
> repository solution to emerge. We'll start with hg, and reconsider bzr
> if it speeds up enough. See preed's blog for why we can't use git or
> other contenders and wannabes.

I see no recent comment on that, and given that reportedly the only real
argument against git is/was that almost half a year ago there was no
well-performing win32 port. This reportedly has changed, so despite some
people telling "git is no option" without bringing forward any current
argument, I think it should be re-evaluated as a third possible choice.
From what I hear, it probably has the most vibrant dev community of all
those choices and works well with a few quite big (in code and community
size) projects - and I tend to think that's something that has value for
Mozilla as well.

> Also do not panic about the above list leaving out mail, mailnews,
> composer, calendar, camino, etc. Mozilla 2 needs focus and the
> repository can grow. Or, with better VCSes such as hg, we can have
> several repositories. With better embedding APIs we won't want to
> tightly couple source of a given XUL app to source of a given Gecko
> back end file. But we will want to keep Firefox and XULRunner building
> at all times. So the above list does include those two.

Well, this means that people working on anything else than Firefox will
probably just not care about that Mozilla2 repo as they can't build
their stuff with/from it. That may be intended, but it creates a major
split within the Mozilla dev community (the privileged who can use
Mozilla2, and the dumb rest that is more or less closed out from it and
whose wishes/bugs/problems won't be looked at a lot there). I'm not sure
this is a good thing to do.
In my eyes, reducing the amount of code managed by the repo just tells
that the new VCS is not as capable as CVS of managing a huge codebase
like the one we have.

Robert Kaiser

Benjamin Smedberg

unread,
Mar 28, 2007, 12:21:39 PM3/28/07
to
Robert Kaiser wrote:

> Well, this means that people working on anything else than Firefox will
> probably just not care about that Mozilla2 repo as they can't build
> their stuff with/from it. That may be intended, but it creates a major
> split within the Mozilla dev community (the privileged who can use
> Mozilla2, and the dumb rest that is more or less closed out from it and
> whose wishes/bugs/problems won't be looked at a lot there). I'm not sure
> this is a good thing to do.

This is a natural continuation of the plans to separate the "core" from the
apps built on top of it. Firefox has a special place here because it is the
primary app used to test the core, and its primary driver.

All of our apps are going to be built on the xulrunner core in the moz2
timeframe, and the repository structure is just a natural extension of that
architecture.

--BDS

Gervase Markham

unread,
Mar 28, 2007, 12:51:51 PM3/28/07
to
Benjamin Smedberg wrote:
> This is a natural continuation of the plans to separate the "core" from the
> apps built on top of it. Firefox has a special place here because it is the
> primary app used to test the core, and its primary driver.
>
> All of our apps are going to be built on the xulrunner core in the moz2
> timeframe, and the repository structure is just a natural extension of that
> architecture.

If the idea is that every XULRunner app apart from Firefox is built by
pulling from 2 (or more) repositories - the core one and the
app-specific one - and combining the result, why not apply the same
logic to Firefox? It would mean that whatever magic is necessary to
perform such a combination is guaranteed to keep working. And it would
guarantee a clean interface between what was platform and what was not.

Gerv

bre...@mozilla.org

unread,
Mar 28, 2007, 1:17:42 PM3/28/07
to
On Mar 28, 5:34 am, T Rowley <t...@acm.org> wrote:
> On 3/27/07 11:40 PM, bren...@mozilla.org wrote:
>
> > Seehttp://wiki.mozilla.org/Mozilla2for more. The initial repository

> > will be a Mercurial one, but don't panic. We need to get to work on
> > Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
> > repository solution to emerge. We'll start with hg, and reconsider bzr
> > if it speeds up enough. See preed's blog for why we can't use git or
> > other contenders and wannabes.
>
> Who is going to be doing this work concurrent with 1.9? All the core
> developers I'm aware of have their plates full getting 1.9 into
> shippable form.

That's why, as blogged and wiki'ed, we're starting with
deCOMtamination, DOM and Tamarin work. jst and I are joining tglek and
dsw on the first two; the Tamarin team, graydon, igor, and other
SpiderMonkey folks will join in due course.

We are going to do two things at once, for a change. This will require
more people. We have more now, and we are recruiting yet more.

/be

bre...@mozilla.org

unread,
Mar 28, 2007, 1:24:53 PM3/28/07
to
On Mar 28, 9:51 am, Gervase Markham <g...@mozilla.org> wrote:
> Benjamin Smedberg wrote:
> > This is a natural continuation of the plans to separate the "core" from the
> > apps built on top of it. Firefox has a special place here because it is the
> > primary app used to test the core, and its primary driver.
>
> > All of our apps are going to be built on the xulrunner core in the moz2
> > timeframe, and the repository structure is just a natural extension of that
> > architecture.
>
> If the idea is that every XULRunner app apart from Firefox is built by
> pulling from 2 (or more) repositories - the core one and the
> app-specific one - and combining the result, why not apply the same
> logic to Firefox?

Because that's a lot of work we don't need to do right now, and can't
afford to do right now. Mozilla 2 is already under way and it needs a
repository. We need working Firefox and XULRunner built on it.

> It would mean that whatever magic is necessary to
> perform such a combination is guaranteed to keep working. And it would
> guarantee a clean interface between what was platform and what was not.

There's no point in perfecting the separation of any given modules
before we start the Mozilla 2 repository. Nor must we do all that work
in the 1.9 time frame -- most of it fits in Mozilla 2 much better. We
are not going to spend all our time first cleaning up widget or gfx,
or removing nss and nsprpub to their own repos, etc. etc. Shaver keeps
attributing Voltaire's "best is the enemy of the good" to me, and what
did Voltaire know? But it fits here.

/be

bre...@mozilla.org

unread,
Mar 28, 2007, 1:31:16 PM3/28/07
to
On Mar 28, 9:16 am, Robert Kaiser <k...@kairo.at> wrote:
> I see no recent comment on that, and given that reportedly the only real
> argument against git is/was that almost half a year ago there was no
> well-performing win32 port. This reportedly has changed, so despite some
> people telling "git is no option" without bringing forward any current
> argument, I think it should be re-evaluated as a third possible choice.
> From what I hear, it probably has the most vibrant dev community of all
> those choices and works well with a few quite big (in code and community
> size) projects - and I tend to think that's something that has value for
> Mozilla as well.

Got a link to pages documenting this git windows work? jst uses git on
cvs today, he keeps up, he's a fan. It's not as if we have it in for
git.

> Well, this means that people working on anything else than Firefox will
> probably just not care about that Mozilla2 repo as they can't build
> their stuff with/from it. That may be intended, but it creates a major
> split within the Mozilla dev community (the privileged who can use
> Mozilla2, and the dumb rest that is more or less closed out from it and
> whose wishes/bugs/problems won't be looked at a lot there).

Nice false dilemma. But since we will give all committers access to
the new repo, and merge trunk changes into Mozilla 2, and keep API
compatibility where we want it (and in all cases, initially), it's
simply not true that anyone is locked out.

Having to host an app elsewhere from the core back end has its pluses
and minuses. It's already being done by the Flocks, Joosts, and
Songbirds of the world. It was done by chimera (camino) initially.
Tinderbox/buildbot coverage is independent of source hosting.

> I'm not sure
> this is a good thing to do.

It's a trade-off:

Pro: focus on Mozilla 2 APIs for Firefox and XULRunner; smaller pull;
more approachable repository (contrast to webkit).

Con: two repositories for other apps; feelings of a division among
apps and people.

If we can use features of the new VCS to host other apps in the new
repo but not obtrusively, we may consider using such features. But now
is not the time to worry about this, before we've committed any of the
automated refactoring patches taras is generating, or done any of the
other more bottom-up/back-to-front work for Moz2.

> In my eyes, reducing the amount of code managed by the repo just tells
> that the new VCS is not as capable as CVS of managing a huge codebase
> like the one we have.

There's no evidence for that.

/be

bre...@mozilla.org

unread,
Mar 28, 2007, 1:34:53 PM3/28/07
to
On Mar 28, 10:31 am, "bren...@mozilla.org" <bren...@mozilla.org>
wrote:

> It's a trade-off:
>
> Pro: focus on Mozilla 2 APIs for Firefox and XULRunner; smaller pull;
> more approachable repository (contrast to webkit).

As I noted in an earlier mail, it also reduces odds of unwanted
coupling to private or other APis.

> Con: two repositories for other apps; feelings of a division among
> apps and people.

Trade-off duality says: it makes it hard for other apps to use secret
APIs they might want to use; it raises the odds of Firefox or
XULRunner using such APIs (but that's arguably ok if other apps are
XULRunner based and do not need such APIs).

/be

Simon Paquet

unread,
Mar 28, 2007, 2:42:43 PM3/28/07
to
Robert Kaiser wrote on 28. Mar 2007:

> Well, this means that people working on anything else than Firefox
> will probably just not care about that Mozilla2 repo as they can't
> build their stuff with/from it. That may be intended, but it creates
> a major split within the Mozilla dev community (the privileged who
> can use Mozilla2, and the dumb rest that is more or less closed out
> from it and whose wishes/bugs/problems won't be looked at a lot
> there). I'm not sure this is a good thing to do.

The split can already be seen in various places and this is just a
consequent continuation of the actions that MoCo has taken in the past
months. It's pretty obvious that people there exclusively care for
Firefox (since it pays their bills and wages) and do not care a bit
about the rest of the Mozilla community.

I just wish that they would openly say so, and not try to tell people
otherwise or blind people's eyes with stuff like the manifesto, which
MoCo obviously has no intention to adhere to.


--
Simon Paquet
Sunbird/Lightning website maintainer
Project website: http://www.mozilla.org/projects/calendar
Developer blog: http://weblogs.mozillazine.org/calendar

Robert Kaiser

unread,
Mar 28, 2007, 2:53:35 PM3/28/07
to
bre...@mozilla.org schrieb:
> git.

From what I've read, the MinGW port of git is working and performing
quite well, it has been started as a fork of mainline git but it is
intended to be merged upstream once someone comes around to introduce
the necessary #ifdefs to sort out what to compile where.

Bulding on MSYS and MinGW, it also would fit well with our targeted
Windows build infrastructure, I guess.

Main sources for this info are the gitweb page of the MinGW port
http://repo.or.cz/w/git/mingw.git as well as its README.MinGW
http://repo.or.cz/w/git/mingw.git?a=blob_plain;f=README.MinGW;hb=master
and the git mailing list g...@vger.kernel.org which I glanced on a few
times via gmame.

> Nice false dilemma. But since we will give all committers access to
> the new repo, and merge trunk changes into Mozilla 2, and keep API
> compatibility where we want it (and in all cases, initially), it's
> simply not true that anyone is locked out.

Well, locked out might be the wrong term. I just quite sure that many
people will just not care about the Mozilla2 repo if working with the
old CVS is not only what they're used to but also a lot easier, not
needing to set up multiple repositories etc.
This in turn will likely keep them away from Mozilla2 work, splitting
the project and removing them from the edge of development (even though
not directly _locking_ them away from it).

It might turn out completely differently, I'm just expressing what I
fear will come out of that.


> It's a trade-off:
>
> Pro: focus on Mozilla 2 APIs for Firefox and XULRunner; smaller pull;
> more approachable repository (contrast to webkit).
>
> Con: two repositories for other apps; feelings of a division among
> apps and people.

Or even more than two, when I think of someone wanting to build
Thunderbird+Lightning at once or even SeaMonkey+Lightning (normal
SeaMonkey can already run into problems with the mailnews backend being
shared with Thunderbird). And what about builds including Venkman or
Chatzilla?

This all is so easy to do with a big shared repository and can get very
complicated with splitted repositories, which makes quite reservated
about that approach.

Another thing is needing to pull a completely different repo just
because you want to help a different project and do a patch for them,
e.g. for webtools or such. With the current approach, the nice thing is
you can easily go, pull that dir in your trunk tree, hack a patch, post
it on bugzilla, check it in after appropriate reviews. Pulling lots of
different repositories in different dirs can easily get annoying enough
that people get scared away from such cross-project help.

> If we can use features of the new VCS to host other apps in the new
> repo but not obtrusively, we may consider using such features.

That would sound nice, but we probably first need to find out what is
easily possible and what not.

I don't want to tell that the approach is wrong, I just want to point
out possible problems we likely will come across, esp. if they hinder us
from getting an even better collaborating community.

Robert Kaiser

bre...@mozilla.org

unread,
Mar 28, 2007, 3:00:03 PM3/28/07
to
On Mar 28, 11:42 am, Simon Paquet <web...@babylonsounds.com> wrote:
> I just wish that they would openly say so, and not try to tell people
> otherwise or blind people's eyes with stuff like the manifesto, which
> MoCo obviously has no intention to adhere to.

Careful with the accusations of dishonesty or at least hypocrisy.

There's strong feeling here, but not much that's true. If we didn't
care about the platform for other apps, we would not take bugfixes,
even late in the cycle or considered for inclusion on a maintenance
branch, for bugs that don't affect Firefox. But we do (see, e.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=362564 or
https://bugzilla.mozilla.org/show_bug.cgi?id=176182).

There ain't no such thing as a free lunch. Firefox pays bills and
more: it creates a faster-moving ecosystem for addons and webapps that
don't face the formidable distribution challenges that XUL App #2
faces. Never mind that we have XUL App #2 (Thunderbird) and it faces
other challenges because *it's not the browser*. I'm not saying a
thick mail client should not be supported by the platform. I am saying
it's bound to place or show, not win. That means it will not
*necessarily* be included in the new repository.

Joost, Songbird, and Flock are not so hosted. Should they be, or our
manifesto talk is all lies? Of course if they were, we would be
accused of selling out to venture-funded startups. We'd have to host
every XUL app, on an equal footing, for some people to be happy.

But we're not going to make everyone happy. We're going to shrink and
speed up our codebase and move the web forward with the big lever,
Firefox, and the platform it's built on, which is codified as
XULRunner. I suggest you argue with facts and bug citations (if you
can find bugs where anyone shortchanged another XUL app without good
reason).

/be

Robert Sayre

unread,
Mar 28, 2007, 3:17:15 PM3/28/07
to bre...@mozilla.org
bre...@mozilla.org wrote:
>
> But we're not going to make everyone happy. We're going to shrink and
> speed up our codebase and move the web forward with the big lever,
> Firefox, and the platform it's built on, which is codified as
> XULRunner. I suggest you argue with facts and bug citations (if you
> can find bugs where anyone shortchanged another XUL app without good
> reason).

All bug citations of that sort, good or bad, are proof that there is a
non-zero coordination cost in the current CVS layout.

Firefox has the leverage to keep the Web open, so that's where the
resources go. It would be completely irresponsible to ignore that
leverage when making allocations. So, a centralized CVS repository comes
with a bureaucracy that must focus on Firefox for a variety of reasons,
and that harms other projects.

The point of switching to hg or bzr or git is to enable a mesh of
repositories rather than one single, lumbering monster. Brendan
correctly points out that this spread is already happening with Joost,
Flock, Zap et al. We need to make it easier. Wouldn't it be nice to pull
changes from XPCOM and Toolkit at will, without the need to negotiate
branch policies with Firefox drivers, and still be able to track the
rest of the repository sanely?

--Rob

bre...@mozilla.org

unread,
Mar 28, 2007, 3:28:13 PM3/28/07
to
On Mar 28, 12:17 pm, Robert Sayre <say...@gmail.com> wrote:

> bren...@mozilla.org wrote:
>
> > But we're not going to make everyone happy. We're going to shrink and
> > speed up our codebase and move the web forward with the big lever,
> > Firefox, and the platform it's built on, which is codified as
> > XULRunner. I suggest you argue with facts and bug citations (if you
> > can find bugs where anyone shortchanged another XUL app without good
> > reason).
>
> All bug citations of that sort, good or bad, are proof that there is a
> non-zero coordination cost in the current CVS layout.

I claim you can cite bugs that demonstrate we've taken patches that
have nothing to do with Firefox, even late in the release cycle. Which
falsifies what I read as Simon's contention that the manifesto is a
lie and we care only about Firefox.

You're right there are non-zero coordination costs -- no free lunch.
This should be, like, "duh" material. That it is not, or that everyone
wants *his* lunch for free, and screw the other guy and Firefox, is
the underlying problem in my view.

> Firefox has the leverage to keep the Web open, so that's where the
> resources go. It would be completely irresponsible to ignore that
> leverage when making allocations.

Yes, good point. You are more explicit than I was, but I said so by
talking about Thunderbird, which has millions of users.

> So, a centralized CVS repository comes
> with a bureaucracy that must focus on Firefox for a variety of reasons,
> and that harms other projects.

This is a good point too. I suspect many folks -- not all -- are
laboring under the limitations, assumptions, and working culture of
the CVS single master repository model.

> The point of switching to hg or bzr or git is to enable a mesh of
> repositories rather than one single, lumbering monster. Brendan
> correctly points out that this spread is already happening with Joost,
> Flock, Zap et al. We need to make it easier. Wouldn't it be nice to pull
> changes from XPCOM and Toolkit at will, without the need to negotiate
> branch policies with Firefox drivers, and still be able to track the
> rest of the repository sanely?

With better merge algs to boot!

/be

bre...@mozilla.org

unread,
Mar 28, 2007, 3:48:17 PM3/28/07
to
On Mar 28, 10:24 am, "bren...@mozilla.org" <bren...@mozilla.org>
wrote:

> On Mar 28, 9:51 am, Gervase Markham <g...@mozilla.org> wrote:
> > Benjamin Smedberg wrote:
> > > All of our apps are going to be built on the xulrunner core in the moz2
> > > timeframe, and the repository structure is just a natural extension of that
> > > architecture.
>
> > If the idea is that every XULRunner app apart from Firefox is built by
> > pulling from 2 (or more) repositories - the core one and the
> > app-specific one - and combining the result, why not apply the same
> > logic to Firefox?
>
> Because that's a lot of work we don't need to do right now, and can't
> afford to do right now. Mozilla 2 is already under way and it needs a
> repository. We need working Firefox and XULRunner built on it.

In addition to the expediency argument, it's clear to me that a dream-
world where the core XULRunner and Gecko code is in one repository,
and Firefox is in another, symmetric with respect to other XUL apps,
is just that: a dream world. I'd like to pick on Gerv's "why not apply
the same logic" question a bit more (he can take it ;-).

Firefox is not "just another XUL app". Mozilla would do a disservice
to everyone in its community, not just "end users", if it pretended
otherwise. Firefox and XULRunner/Gecko are the big lever we have to
advance the web. And with the right fulcrum, we may be able to move
mountains. We cannot treat all XUL apps equally in practice, even in
an ideal world. Practically speaking, we are willing to couple Firefox
to the back end, as it is today, via unfrozen APIs.

We aspire to freeze all such APIs. But if we don't succeed by any
given release (e.g., Firefox 4 on top of Mozilla 2), then we will
couple front to back end within the new repository.

/be

bre...@mozilla.org

unread,
Mar 28, 2007, 4:46:29 PM3/28/07
to
On Mar 28, 11:53 am, Robert Kaiser <k...@kairo.at> wrote:
[git news snipped]

We'll need to evaluate the situation, but we need to move now. We've
already delayed enough evaluating bzr. All these VCSes are moving
targets, and we can't keep trying the latest unmerged experiment or
port or we will never pick one and move. Again, we can switch later,
especially once we have moved to a changeset based system. It's
clearly wrong to say "we've picked the right system for the next ten
years". But (see below) it's also wrong to stick with CVS for Mozilla
2.

> > Nice false dilemma. But since we will give all committers access to
> > the new repo, and merge trunk changes into Mozilla 2, and keep API
> > compatibility where we want it (and in all cases, initially), it's
> > simply not true that anyone is locked out.
>
> Well, locked out might be the wrong term.

It is.

> I just quite sure that many
> people will just not care about the Mozilla2 repo if working with the
> old CVS is not only what they're used to but also a lot easier, not
> needing to set up multiple repositories etc.

Well, now you are changing your argument. If some users don't want
anything but CVS, they will indeed be stuck. But the Mozilla project's
future after 1.9 is Mozilla 2. cvs.mozilla.org will live forever, but
the main line of development, the place where sustained security bug-
fixing and rearchitecture, Tamarin integration, performance work,
embedding API that we can support, etc., will be the new repository.

It's silly to say "people will just use CVS because it's too hard to
use two VCSes" given this. If you believe we will fail at Mozilla 2,
say so. If you think there's something other than CVS that will favor
too many people in the community sticking with cvs.mozilla.org in
perpetuity, I'd like to hear what that something else might be.

> This in turn will likely keep them away from Mozilla2 work, splitting
> the project and removing them from the edge of development (even though
> not directly _locking_ them away from it).

Your argument now is that we can never move from CVS to a new VCS
because it would split the community. But that is false, given all the
folks already using new VCSes layered on top-of-trunk pulls from CVS.
And it ignores all the wins of the new VCSes, some of which are
necessary for Mozilla 2.

/be

Simon Paquet

unread,
Mar 28, 2007, 5:47:27 PM3/28/07
to
bre...@mozilla.org wrote on 28. Mar 2007:

>> I just wish that they would openly say so, and not try to tell
>> people otherwise or blind people's eyes with stuff like the
>> manifesto, which MoCo obviously has no intention to adhere to.
>
> Careful with the accusations of dishonesty or at least hypocrisy.
>
> There's strong feeling here, but not much that's true. If we didn't
> care about the platform for other apps, we would not take bugfixes,
> even late in the cycle or considered for inclusion on a maintenance
> branch, for bugs that don't affect Firefox. But we do (see, e.g.,
> https://bugzilla.mozilla.org/show_bug.cgi?id=362564 or
> https://bugzilla.mozilla.org/show_bug.cgi?id=176182).

There's a difference between caring about the platform all of the
time (and thereby adhering to the manifesto) or doing so only some
of the time, which is my impression.

Just to be clear, I'm *not* calling you or other people from MoCo
a huge bunch of liars, who are betraying the project. That wouldn't
be true. But I see more and more indications that the project is
moving from the "multitude of products with a premier app" point to
the "One premier app and a bunch of other stuff which we tolerate
unless it does not get in our way" point.

The first one is fine, the second one is not. This feels more and
more like the days, when Netscape dominated the project and alienated
more people than it helped to recruit for the project.

> There ain't no such thing as a free lunch. Firefox pays bills

Yes. And as a Firefox user/QA supporter from the m/b days I really
appreciate that and all the good it has brought to the project.

> Never mind that we have XUL App #2 (Thunderbird) and it faces
> other challenges because *it's not the browser*. I'm not saying a
> thick mail client should not be supported by the platform. I am
> saying it's bound to place or show, not win. That means it will
> not *necessarily* be included in the new repository.

What I really don't understand (maybe my lack of knowledge of VCSs
besides CVS is the reason) is, why the new repository must be
restricted to the core code and Firefox? What do we lose if we
add the other stuff like mail, mailnews, calendar, suite?

> Joost, Songbird, and Flock are not so hosted. Should they be, or
> our manifesto talk is all lies?

Don't you think that there is a huge difference between official
mozilla.org projects sustained by a real community and products
outside of mozilla.org, which are funded with VC money.

> But we're not going to make everyone happy. We're going to shrink
> and speed up our codebase

How will a restricted repository speed things up. You can already
restrict your cvs pull to directories which are needed by Firefox
and not pull the stuff in mail, mailnews, calendar or suite. Is that
not possible in Mercurial?

bre...@mozilla.org

unread,
Mar 28, 2007, 6:21:12 PM3/28/07
to
On Mar 28, 2:47 pm, Simon Paquet <web...@babylonsounds.com> wrote:

> bren...@mozilla.org wrote on 28. Mar 2007:
> > There's strong feeling here, but not much that's true. If we didn't
> > care about the platform for other apps, we would not take bugfixes,
> > even late in the cycle or considered for inclusion on a maintenance
> > branch, for bugs that don't affect Firefox. But we do (see, e.g.,
> >https://bugzilla.mozilla.org/show_bug.cgi?id=362564or
> >https://bugzilla.mozilla.org/show_bug.cgi?id=176182).
>
> There's a difference between caring about the platform all of the
> time (and thereby adhering to the manifesto) or doing so only some
> of the time, which is my impression.

This flunks my "no free lunch", "scarcity is everywhere", "utopia is
not an option" test. No group or individual can "care" about
everything all of the time. Period, end of story!

There are trade-offs. One of the obvious ones where trademark,
marketing, and build/qa are invested, and we have the "products" vs.
"projects" solution in place. Even here, as noted, Firefox >>
Thunderbird for good, particular reasons.

> Just to be clear, I'm *not* calling you or other people from MoCo
> a huge bunch of liars, who are betraying the project. That wouldn't
> be true.

Ok, good to hear.

> But I see more and more indications that the project is
> moving from the "multitude of products with a premier app" point to
> the "One premier app and a bunch of other stuff which we tolerate
> unless it does not get in our way" point.

This is a "feelings" sort of judgment that it's fruitless to argue
about. I assert, and will be working hard to make true, that Mozilla 2
will *improve* the lives of all XUL apps compared to the unitary CVS
repository and the mess of embedding and other APIs, plus the
footprint, performance, and security problems of today.

> The first one is fine, the second one is not. This feels more and
> more like the days, when Netscape dominated the project and alienated
> more people than it helped to recruit for the project.

Let's try to get away from arguing about feelings. First, I think you
and I do not see eye to eye on scarcity being the fundamental fact of
economic life, including in Mozilla. Second, I think you want
something (hosting of calendar in the Moz2 repo from day 1) that is
unreasonable, and that may even be harmful to both calendar and
Mozilla 2.

Let's talk about these two things in concrete terms, if we can.

> > There ain't no such thing as a free lunch. Firefox pays bills
>
> Yes. And as a Firefox user/QA supporter from the m/b days I really
> appreciate that and all the good it has brought to the project.

Good to know too. I'm still not sure how your "caring about" above can
be reconciled with this understanding. If we cared less about the
suite -- and we did -- and that focus on the new standalone apps was
good for the project, then it's conceivable that the same focus and
better VCS tools can improve the lives of XUL app hackers, even if (or
*because*) their app sources are not hosted in the same repo as the
core code.

That Firefox will be co-hosted is a necessity, as I've written. If in
the very long run, Gerv's symmetric dream comes true (I'm frankly
skeptical), great. There's no _a priori_ reason that can't happen. All
of my skepticism is based on _a posteriori_ reasoning from experience
with Mozilla and other large systems that have "back end" and "front
end" code.

> > Never mind that we have XUL App #2 (Thunderbird) and it faces
> > other challenges because *it's not the browser*. I'm not saying a
> > thick mail client should not be supported by the platform. I am
> > saying it's bound to place or show, not win. That means it will
> > not *necessarily* be included in the new repository.
>
> What I really don't understand (maybe my lack of knowledge of VCSs
> besides CVS is the reason) is, why the new repository must be
> restricted to the core code and Firefox?

As I've already listed:

1. To keep it small and approachable.
2. To avoid entangling other apps with private or otherwise non-public
APIs.
3. To keep focused on Firefox *and* XULRunner, so the fast-moving
ecosystem built on both is better served, with priority to Firefox as
ever (see sayrer's posts too).

> What do we lose if we
> add the other stuff like mail, mailnews, calendar, suite?

No one working on them in the short run. Loss of focus if we have to
divide our time between rearchitecture that strengthens the APIs and
the core code, and that maintains more compatibility than Mozilla 2
could otherwise get away with. And the enganglements noted above.

We have significant problems today solving bugs bottom-up instead of
rearchitecting, while keeping backward compatibility at the API
layers. For Mozilla 2, this means we can break compatibility. If we
only have to worry about Firefox and XULRunner, then we may break some
semi-public or private API that Thunderbird uses, and it can "port" to
a better API we provide, later. Or it can join the party and add that
better API.

We do not do anyone, including Thunderbird (just to pick on it; could
be calendar stuff too) by serving multiple masters and "caring" about
too much. We need focus on Firefox and XULRunner, with other apps
joining the party at the XULRunner API negotiation layer, some time
after our initial work is well under way.

> > Joost, Songbird, and Flock are not so hosted. Should they be, or
> > our manifesto talk is all lies?
>
> Don't you think that there is a huge difference between official
> mozilla.org projects sustained by a real community and products
> outside of mozilla.org, which are funded with VC money.

What's this non-sequitur about? I explicitly cited their funding
status in the next sentence, which you do not cite. If your point is
that we should care more in practical ways about the non-funded XUL
apps, in ways that disrupt Mozilla 2's Firefox and XULRunner focus,
then I can't agree. We should not care more about any XUL app, funded
or not. They should all bring technical arguments to bear in favor of
API additions or changes, and their hackers should contribute patches.

It should not matter that "Sunbird's volunteer crew needs this API" or
"Joost needs this API" or "Simon needs this API". What should matter
is the API's form and fit, its security properties, the cost and
degree of its implementation(s), what happens to the overwhelming
majority of API consumers if we leave it out, and other such
considerations that can be judged according to shared technical
values.

Even a minority API user cohort can have influence based on technical
arguing, for sure. But we are not going to play favorites for or
against commercial and volunteer groups or individuals. We need to
continue to uphold a shared technical vision and values, with common
vocabulary and good reputation-system support, or we are doomed.

> > But we're not going to make everyone happy. We're going to shrink
> > and speed up our codebase
>
> How will a restricted repository speed things up. You can already
> restrict your cvs pull to directories which are needed by Firefox
> and not pull the stuff in mail, mailnews, calendar or suite. Is that
> not possible in Mercurial?

It's possible with Hg actually, but not with all such systems. So the
reasons I gave above for focus, entanglement-proofing, and
approachability are the reasons, not any particular VCS limitation. If
adding another XUL app to the Mozilla 2 repo is the right thing, we
can do it. But we won't at the start, just to have unowned in the
Mozilla 2 repo, auto-merged versions of those apps' sources.

/be

bre...@mozilla.org

unread,
Mar 28, 2007, 6:50:32 PM3/28/07
to
Lack of lunch left my last post short a couple of verbs -- sorry about
that. Corrections below.

On Mar 28, 3:21 pm, "bren...@mozilla.org" <bren...@mozilla.org> wrote:
> There are trade-offs. One of the obvious ones where trademark,

"is" between "ones" and "where".

> marketing, and build/qa are invested, and we have the "products" vs.
> "projects" solution in place. Even here, as noted, Firefox >>
> Thunderbird for good, particular reasons.

[snip]


> We do not do anyone, including Thunderbird (just to pick on it; could
> be calendar stuff too) by serving multiple masters and "caring" about

Either s/We do not do/We do not help/ or (what I meant to write) "We
do not do anyone ... any favors by ...."

/be

Christian Biesinger

unread,
Mar 28, 2007, 7:48:10 PM3/28/07
to
bre...@mozilla.org wrote:
> Here is the minimal list of files and directories, including their
> subdirectories in the case of directories, from under
> cvs.mozilla.org's mozilla top-level directory, that I propose we
> migrate into the Mozilla 2 initial repository:

Will you import the entire modules/, or just what is also part of a
normal checkout?

Are you intentionally leaving out configure? (I wouldn't mind that)

bre...@mozilla.org

unread,
Mar 28, 2007, 7:51:40 PM3/28/07
to
On Mar 28, 4:48 pm, Christian Biesinger <cbiesin...@web.de> wrote:

> bren...@mozilla.org wrote:
> > Here is the minimal list of files and directories, including their
> > subdirectories in the case of directories, from under
> > cvs.mozilla.org's mozilla top-level directory, that I propose we
> > migrate into the Mozilla 2 initial repository:
>
> Will you import the entire modules/, or just what is also part of a
> normal checkout?

Normal checkout, I think. Benjamin will do the deed, so I defer to
him.

> Are you intentionally leaving out configure? (I wouldn't mind that)

This is another one for Benjamin, but if we need it committed today
(and we do), then let's not hold up the Moz2 initial repo just to
polish this tiny bump to be a bit smoother.

/be

Christian Biesinger

unread,
Mar 28, 2007, 7:52:43 PM3/28/07
to
bre...@mozilla.org wrote:
> Firefox is not "just another XUL app". Mozilla would do a disservice
> to everyone in its community, not just "end users", if it pretended
> otherwise. Firefox and XULRunner/Gecko are the big lever we have to
> advance the web. And with the right fulcrum, we may be able to move
> mountains. We cannot treat all XUL apps equally in practice, even in
> an ideal world. Practically speaking, we are willing to couple Firefox
> to the back end, as it is today, via unfrozen APIs.

C'mon, Firefox does not need to limit itself to frozen APIs just because
it lives in a different repository.

bre...@mozilla.org

unread,
Mar 28, 2007, 8:05:31 PM3/28/07
to
On Mar 28, 4:52 pm, Christian Biesinger <cbiesin...@web.de> wrote:

I'm not saying that. I'm arguing that we can make a "backroom deal"
for Firefox that we do not support for anyone else, that does not show
up in the DLL exports. Of course, Songbird or whomever could
understand how that deal works, hack the code they pull or import, and
use the same deal. It's all user-land software, no kernel-controlled
hardware MMU to enforce integrity properties. But with a new
repository, I'm more confident we could say "no" to "you must not
break my illicit use of your backroom deal API" demands.

/be

Christian Biesinger

unread,
Mar 28, 2007, 8:09:12 PM3/28/07
to
bre...@mozilla.org wrote:
> This is another one for Benjamin, but if we need it committed today
> (and we do), then let's not hold up the Moz2 initial repo just to
> polish this tiny bump to be a bit smoother.

Well, "need"... Even today, we could say "developers need to have
autoconf 2.13 installed", and have client.mk run that before running
configure. Few projects have generated files like that checked in.

I suppose the main issue here would be Windows, but we could include
autoconf 2.13 in MozillaBuild.

Christian Biesinger

unread,
Mar 28, 2007, 8:12:01 PM3/28/07
to
bre...@mozilla.org wrote:
> On Mar 28, 4:52 pm, Christian Biesinger <cbiesin...@web.de> wrote:
>> C'mon, Firefox does not need to limit itself to frozen APIs just because
>> it lives in a different repository.
>
> I'm not saying that. I'm arguing that we can make a "backroom deal"
> for Firefox that we do not support for anyone else, that does not show
> up in the DLL exports.

Perhaps you could clarify, when you say "unfrozen API", what do you
mean? For me, it mainly means unfrozen interfaces (IDL).

It seems like you mean the unfrozen C++ symbols, basically the stuff we
currently export from xpcom_core, including the internal string API?

bre...@mozilla.org

unread,
Mar 28, 2007, 8:28:48 PM3/28/07
to
On Mar 28, 5:12 pm, Christian Biesinger <cbiesin...@web.de> wrote:

Here I am not up to date with Benjamin's work, but last I checked, it
was possible (easy on Windows, hard with the GCC toolchain but
possible) to hide all symbols except those that come from specially
decorated declarations (whether or not those C++ declarations came
from IDL primary sources). We definitely want to hide symbols in
libXUL (whatever-its-called) that are needed only "inside" the back
room (where the deal happens).

Again this is not hack-proof, and I don't want to make too much of it.
When I was writing about entanglements between app front ends and back
end code, I was not talking about intentional dependencies so much.
Those can be good, and solid APIs should be negotiated to serve all
use-cases that pass muster with the relevant owners and high-
reputation onlookers.

I was more concerned with unintended entanglement and requirement
overload. Having separate repositories is not an iron-clad guarantee
against such entanglement, but it mitigates the problem.

/be

Benjamin Smedberg

unread,
Mar 28, 2007, 9:25:53 PM3/28/07
to

configure-2.13 is already in mozillabuild. However, there are plenty of
linux distros that do not come with it by default (requires a special
package), and I don't want to spend the time trying to get the generated
file into release tarballs that isn't in CVS. So for the moment, I will
import configure.

--BDS

Robert Kaiser

unread,
Mar 28, 2007, 9:27:38 PM3/28/07
to
bre...@mozilla.org schrieb:

> It's silly to say "people will just use CVS because it's too hard to
> use two VCSes" given this. If you believe we will fail at Mozilla 2,
> say so. If you think there's something other than CVS that will favor
> too many people in the community sticking with cvs.mozilla.org in
> perpetuity, I'd like to hear what that something else might be.

This is completely NOT a case of which VCS we're using for Mozilla2, all
I'm talking about there is what code is in there. Needing to puzll from
4-5 repositories for just being able to build SeaMonkey sounds horrible
to me, no matter if they are CVS, hg, bzr, git or whatever.

My real problem is that I think for many people working on non-Firefox
apps it will be a lot harder to work with Mozilla2 as they need to set
up multiple (at least 2, if not more) repositories to pull from just to
get a current trunk build.

And they need to set up even more repositories if they want to just help
some other related project with some code.

Rather than doing that, they will probably stay with the monolithic CVS
tree instead of moving to a more modern VCS and not help other projects
within the community, as all that gets just annoyingly difficult. That's
what I fear. And that's nothing to do with the monolithic current repo
being CVS and the splitted ones being something else, actually. It's
just about the splitting of the mozilla.org tree that you're arbitrarily
introducing here.

Robert Kaiser

Robert Kaiser

unread,
Mar 28, 2007, 9:30:31 PM3/28/07
to
bre...@mozilla.org schrieb:

> This is a good point too. I suspect many folks -- not all -- are
> laboring under the limitations, assumptions, and working culture of
> the CVS single master repository model.

Actually, I see more enabling of freedom and collaboration in that model
than I see any limitations. YMMV, though, I guess.

Robert kaiser

Robert Sayre

unread,
Mar 28, 2007, 10:15:11 PM3/28/07
to Robert Kaiser

I do not see any "enabling of freedom" on CVS's part, whatever that
might be. You'll have to be more specific.

I do agree with your second point, but I want to change the word from
"collaboration" to "findability".[1] This is a real hazard of a
decentralized VCS. It will be more difficult to keep tabs on each
other's work if we aren't careful.

However, I have two problems with the way you've characterized the
interaction of the projects. The first objection is that JS, Gecko, and
Firefox/Toolkit don't/won't depend on Seamonkey. There is no findability
hazard if those projects aren't located near Seamonkey. Presumably,
Seamonkey devs will know where to find Gecko. The second is objection is
the unspoken assumption that developers working on Firefox will retreat
to a cliquish single repository. That will not be the case, and the
findability hazard will in fact be greater for Firefox and Gecko
hackers, because work from Graydon, Taras, etc. is likely to result in a
lot of code moving in many directions between many repositories.

Your other message vastly overstates the coordination cost of separate
repositories, imho. That is what these tools are designed to do.

- Rob

[1] http://en.wikipedia.org/wiki/Findability

Boris Zbarsky

unread,
Mar 28, 2007, 10:51:46 PM3/28/07
to
Robert Sayre wrote:
> However, I have two problems with the way you've characterized the
> interaction of the projects. The first objection is that JS, Gecko, and
> Firefox/Toolkit don't/won't depend on Seamonkey.

In practice, this is false. At the moment I pull (and build) Firefox,
XULRunner, Thunderbird, Seamonkey, and calendar just because I've made changes
in the past to core code that broke (as in "tree is red") some subset of those
because they were using C++ APIs that I changed. So unless you're suggesting
that someone who changes core APIs is not responsible for updating existing
consumers, I'm not sure how you envision this working.

Until we get to that holy grail of apps only using frozen core APIs, of course. ;)

That said, I agree that having to maintain all those apps for every single
(possibly experimental) API change in the mozilla2 tree is not something we want
to be doing. So I think the plan of just doing the initial stuff with Firefox,
then making sure all the changes work correctly with all apps later once we're
happy with it is the right thing in the short term. Long-term, we should think
about how we want to handle this.

-Boris

bre...@mozilla.org

unread,
Mar 29, 2007, 1:11:32 AM3/29/07
to
On Mar 28, 6:27 pm, Robert Kaiser <k...@kairo.at> wrote:
> This is completely NOT a case of which VCS we're using for Mozilla2, all
> I'm talking about there is what code is in there. Needing to puzll from
> 4-5 repositories for just being able to build SeaMonkey sounds horrible

Why 4-5? The number should be <= 2 unless you add unstated
requirements that are not being proposed.

/be

Robert Kaiser

unread,
Mar 29, 2007, 7:20:41 AM3/29/07
to
bre...@mozilla.org schrieb:

I based this on the assumption that XULRunner, SeaMonkey-specific code,
venkman, Lightning, Chatzilla, might all live in different repositories
but we want to build them all into one suite, as that's what SeaMonkey
is, in fact.

Maybe this assumption is completely wrong, but I can only assume how the
development model is really supposed to look, as I've seen no clear
description of it anywhere yet.

Robert Kaiser

Message has been deleted

Robert Kaiser

unread,
Mar 29, 2007, 7:25:05 AM3/29/07
to
bre...@mozilla.org schrieb:

> On Mar 28, 6:27 pm, Robert Kaiser <k...@kairo.at> wrote:
>> This is completely NOT a case of which VCS we're using for Mozilla2, all
>> I'm talking about there is what code is in there. Needing to pull from

>> 4-5 repositories for just being able to build SeaMonkey sounds horrible
>
> Why 4-5? The number should be <= 2 unless you add unstated
> requirements that are not being proposed.

I based this on the assumption that XULRunner, SeaMonkey-specific code,
shared mailnews code, venkman, Lightning, Chatzilla, might all live in

Robert Kaiser

unread,
Mar 29, 2007, 7:34:38 AM3/29/07
to
Robert Sayre schrieb:

> Robert Kaiser wrote:
>> bre...@mozilla.org schrieb:
>>> This is a good point too. I suspect many folks -- not all -- are
>>> laboring under the limitations, assumptions, and working culture of
>>> the CVS single master repository model.
>>
>> Actually, I see more enabling of freedom and collaboration in that
>> model than I see any limitations. YMMV, though, I guess.
>
> I do not see any "enabling of freedom" on CVS's part, whatever that
> might be. You'll have to be more specific.

As I said elsewhere, this is not CVS vs. other VCSes, but monolithic vs.
split trees, but I think you based your argument on that anyways.

I meant the freedom to easily help other projects with a fast patch,
include works from others in your app, etc. - which is quite easy if you
just need to pull an additional dir from the same repo.

> The second is objection is
> the unspoken assumption that developers working on Firefox will retreat
> to a cliquish single repository. That will not be the case, and the
> findability hazard will in fact be greater for Firefox and Gecko
> hackers, because work from Graydon, Taras, etc. is likely to result in a
> lot of code moving in many directions between many repositories.

OK, that's private vs. "the official" repositories, which will
frequently merge patchsets, I guess, and that's just how a decentralized
VCS works. Good.

Pulling non-official-trunk code for at-the-edge development of other
apps harms collaboration on the main code and fast finding of problems
on main core development source. So if the model is expected to be that
e.g. SeaMonkey has a copy of trees of all included code just in its
"official" working repository and merges that from time to time, you'll
come to the situation where SeaMonkey, Firefox, Thunderbird, Sunbird,
etc. rarely work with any similar copy of XULRunner and someone (like
me) who's currently used to pull and build all of them daily to test
some of his code with other apps just will start to ignore anything but
the main app he's working on. Which harms all our projects, IMHO.

But I guess the pull once, build multiple apps approach is just
something the decisionmakers here don't care about much.

> Your other message vastly overstates the coordination cost of separate
> repositories, imho. That is what these tools are designed to do.

I guess that depends on how you deal with that. If it means pulling the
"trunk" (or whatever we'll call it there) from several different
repositories just to build your app, it might get difficult. If the
development model is what I described above, I see those problem I
described there arising.

Robert Kaiser

Robert Kaiser

unread,
Mar 29, 2007, 7:38:55 AM3/29/07
to
Boris Zbarsky schrieb:

> Robert Sayre wrote:
>> However, I have two problems with the way you've characterized the
>> interaction of the projects. The first objection is that JS, Gecko,
>> and Firefox/Toolkit don't/won't depend on Seamonkey.
>
> In practice, this is false. At the moment I pull (and build) Firefox,
> XULRunner, Thunderbird, Seamonkey, and calendar just because I've made
> changes in the past to core code that broke (as in "tree is red") some
> subset of those because they were using C++ APIs that I changed. So
> unless you're suggesting that someone who changes core APIs is not
> responsible for updating existing consumers, I'm not sure how you
> envision this working.

From what I see in this discussion, the target is that other apps can
happily be broken because they live elsewhere and don't merge current
dev source into their base code until release time nears. And then, when
a XULRunner beta (or even final) has been done, they'll file all kind of
bugs about incompatibilities of APIs with non-FF apps that haven't been
tested when the APIs where invented because everyone else than FF lived
at a different codebase.
If the APIs can still be fixed at that point, I guess everything's fine,
else they'll just ship their modified XULRunner versions with their
apps, I guess...

Robert Kaiser

Benjamin Smedberg

unread,
Mar 29, 2007, 9:39:11 AM3/29/07
to
Robert Kaiser wrote:

> I guess that depends on how you deal with that. If it means pulling the
> "trunk" (or whatever we'll call it there) from several different
> repositories just to build your app, it might get difficult. If the

Why is that difficult? We will certainly have a client.mk-like solution to
pull the repositories together (just as we pull l10n/ and mozilla/ together
today). We are actively working on a non-monolithic configure system so that
you can build arbitrary apps on top of the core without hacking the main
configure scripts.

I don't see any need for SeaMonkey (for example) to maintain its own version
of the gecko core tree. Just use the standard one. Other more complex apps
such as Joost would use their own version, because they have hacked the
core. But the distributed VCS makes it much easier for them to track the
main tree and contribute changesets back.

--BDS

Benjamin Smedberg

unread,
Mar 29, 2007, 9:48:41 AM3/29/07
to
Robert Kaiser wrote:

> From what I see in this discussion, the target is that other apps can
> happily be broken because they live elsewhere and don't merge current
> dev source into their base code until release time nears. And then, when
> a XULRunner beta (or even final) has been done, they'll file all kind of
> bugs about incompatibilities of APIs with non-FF apps that haven't been
> tested when the APIs where invented because everyone else than FF lived
> at a different codebase.

It *is* the goal that core+firefox development can happen rapidly, and that
it's ok to break other apps along the way. The opportunity and resources we
have as a project should be focused on that combination, and we cannot
afford the coordination costs to keep everything (tbird, camino, etc)
unbroken all the time.

It is absolutely *not* the goal for each project to have their own fork of
the core repository, and it's silly or disingenious to state that it is.

The other projects have various ways they can coordinate:

1) they can pull and build on the trunk xulrunner and fix bustages as they come.
2) they can pull from known-good revisions of the xulrunner repo and upgrade
as appropriate (nightly/weekly)
3) they can wait for API stability points (e.g. feature-complete betas) and
upgrade "late".

Different projects may use different strategies, depending on the resources
at their disposal. Obviously using the trunk xulrunner (constantly or
frequently) will reduce the opportunities for major regressions.

--BDS

Robert Kaiser

unread,
Mar 29, 2007, 10:12:30 AM3/29/07