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

brendan@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

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

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

brendan@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

Gervase Markham wrote:

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

On 3/27/07 11:40 PM, brendan@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.

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

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

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

brendan@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

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

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

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

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

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

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

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 
consequent continuation of the actions that MoCo has taken in the pas
months. It's pretty obvious that people there exclusively care fo
Firefox (since it pays their bills and wages) and do not care a bi
about the rest of the Mozilla community

I just wish that they would openly say so, and not try to tell peopl
otherwise or blind people's eyes with stuff like the manifesto, whic
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

brendan@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 git@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

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

brendan@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

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

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

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

brendan@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 th
time (and thereby adhering to the manifesto) or doing so only som
of the time, which is my impression

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

The first one is fine, the second one is not. This feels more an
more like the days, when Netscape dominated the project and alienate
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 reall
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 VCS
besides CVS is the reason) is, why the new repository must b
restricted to the core code and Firefox? What do we lose if w
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 officia
mozilla.org projects sustained by a real community and product
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 alread
restrict your cvs pull to directories which are needed by Firefo
and not pull the stuff in mail, mailnews, calendar or suite. Is tha
not possible in Mercurial

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

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

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

brendan@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)

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

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

On Mar 28, 4:52 pm, Christian Biesinger <cbiesin...@web.de> wrote:
> bren...@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.

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

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

brendan@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?

On Mar 28, 5:12 pm, Christian Biesinger <cbiesin...@web.de> wrote:
> bren...@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?

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

Christian Biesinger wrote:
> brendan@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.

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

brendan@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

brendan@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 Kaiser wrote:
> brendan@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.

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

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

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

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

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

brendan@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 
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

Robert Sayre schrieb:
> Robert Kaiser wrote:
>> brendan@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

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

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

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

Benjamin Smedberg schrieb:
> 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.

OK, I just hope that without having Firefox using that same approach 
this client.mk-style solution will be cared about enough, as the project 
I (obviously) care about most will need to use that quite heavily ;-)

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

OK, that sounds sane. I just hope that automatic pulling of multiple 
repositories (by client.mk or whatever) will work soon enough so that 
other projects can jump on the Mozilla2 train.

(Just like I actually _do_ hope that all XUL-based apps will break 
heavily with Mozilla2, as I hope everyone will be forced to using L20n 
at some point *g* - knowing how cool that technology is supposed to be)

Robert Kaiser

Benjamin Smedberg schrieb:
> 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.

That's fine in the times where the really big changes are happening 
(major API redesigns, L20n, etc.) - but with minor API changes (as we 
have them all the time in current 1.x trees), it's very helpful if the 
author of the original API patch just can do a tree-wide replace of 
calling functions, etc. as it's often done today. Very often that's a 
5-minutes-job for that API patch author, but a one-hour-job for someone 
of the respective other project as he has to study the details of the 
API change before applying it to code across his project.
In the case of Mozilla 1.x -> Mozilla 2, people probably have to relearn 
a bigger number of APIs anyhow, so it might be OK to bite the bullet for 
that conversion. Not sure about incremental changes after that, though.

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

OK, good. As the planned development model hasn't been layed out, I just 
wanted to make sure what it looks like in this respect.
I'm relieved myself that it is what you pointed out, despite potential 
problems of the multi-repository approach. But then, no approach is 
without problems or downsides. I just wanted to ensure that those are 
being thought about, so solutions can be found way before problem get 
too big.

Robert Kaiser

Benjamin Smedberg wrote:
> It *is* the goal that core+firefox development can happen rapidly, and that
> it's ok to break other apps along the way.

In the short term, right?  Or is this the proposed model going forward indefinitely?

As in, is this the model for the mozilla2 work while most app work is still on 
1.9, or is this a proposal for a change to the tree rules for the Mozilla 
project as a whole going forward?

> 1) they can pull and build on the trunk xulrunner and fix bustages as they come.

This is the current model for mozilla.org apps, basically, except the tree rules 
explicitly say that fixing compilation issues is the patch committer's 
responsibility.  Are we changing that?  If so, where was the discussion that led 
to that decision?

-Boris

Boris Zbarsky wrote:
> Benjamin Smedberg wrote:
>> It *is* the goal that core+firefox development can happen rapidly, and
>> that
>> it's ok to break other apps along the way.
> 
> In the short term, right?  Or is this the proposed model going forward
> indefinitely?
> 
> As in, is this the model for the mozilla2 work while most app work is
> still on 1.9, or is this a proposal for a change to the tree rules for
> the Mozilla project as a whole going forward?

Brendan may have other thoughts, but I believe this should be the policy
going forward indefinitely. e.g. core/firefox hackers should not be
responsible for unbreaking SM or TB. This is how I work with the Camino team
right now: I try to let them know when I'm making build system changes that
might break the tree, and let them know how to fix it, but I don't build or
fix camino myself.

I know this is is a change from current policy, and should be discussed, but
I don't think it affects the repository layout.

--BDS

Benjamin Smedberg wrote:
> I know this is is a change from current policy, and should be discussed, but
> I don't think it affects the repository layout.

Agreed on both counts.  For what it's worth, I think this is an undesirable 
change, and look forward to the discussion on it.  ;)

-Boris

Benjamin Smedberg wrote:
> Boris Zbarsky wrote:
>> Benjamin Smedberg wrote:
>>> It *is* the goal that core+firefox development can happen rapidly, and
>>> that
>>> it's ok to break other apps along the way.
>> In the short term, right?  Or is this the proposed model going forward
>> indefinitely?
>>
>> As in, is this the model for the mozilla2 work while most app work is
>> still on 1.9, or is this a proposal for a change to the tree rules for
>> the Mozilla project as a whole going forward?
> 
> Brendan may have other thoughts, but I believe this should be the policy
> going forward indefinitely. e.g. core/firefox hackers should not be
> responsible for unbreaking SM or TB. This is how I work with the Camino team
> right now: I try to let them know when I'm making build system changes that
> might break the tree, and let them know how to fix it, but I don't build or
> fix camino myself.
> 
> I know this is is a change from current policy, and should be discussed, but
> I don't think it affects the repository layout.
> 
> --BDS

There is a difference between what you do and having it "be ok to break 
other apps", though. Clearly you're being *aware* that your changes 
might break other apps, and you try to let them know if you think that's 
the case. That's different from ignoring them altogether and finding out 
second-hand after 3 weeks that another dev team is annoyed at you 
because one of your code changes actually fudged mail(news) or calendar 
or irc or venkman or Bob knows what else.

~ Gijs

On Mar 29, 8:58 am, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> Brendan may have other thoughts, but I believe this should be the policy
> going forward indefinitely. e.g. core/firefox hackers should not be
> responsible for unbreaking SM or TB. This is how I work with the Camino team
> right now: I try to let them know when I'm making build system changes that
> might break the tree, and let them know how to fix it, but I don't build or
> fix camino myself.

So not totally new policy.

> I know this is is a change from current policy, and should be discussed, but
> I don't think it affects the repository layout.

But new enough, and as you note independent of the source hosting, to
bring up in a new thread?

I'm obviously in favor. Mozilla 2 has to consider various apps, but
not at once and all the time. The goal is to support lots of apps via
better embedding APIs. But the way to get there is not continuously
integrating with a large number of apps, some of which can't afford to
track core API changes at the same pace that the core and Firefox and
XULRunner must move.

/be

brendan@mozilla.org wrote:
> But new enough, and as you note independent of the source hosting, to
> bring up in a new thread?

imo, yes.

-Boris

brendan@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:

I notice the JavaScript Debugger (extensions/venkman) isn't on the list. 
  Any particular reason why not?

Alex

brendan@mozilla.org wrote:

I have removed the following from the list, because I don't think we want
them in this repo:

> extensions/cck
> extensions/datetime
> extensions/finger

--BDS

brendan@mozilla.org wrote:

I have also removed themes/, which is suite-specific.

--BDS

Alex Vincent wrote:
> brendan@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:
> 
> I notice the JavaScript Debugger (extensions/venkman) isn't on the list. 
>  Any particular reason why not?

Neither is ChatZilla (extensions/irc), both of which I think are good 
decisions for the moment.

The Mozilla 2 repository is not meant to build anything except XULRunner 
and Firefox, at least for now, and until the location of any suite-only 
items is decided (assuming that is to move at all) there should be no 
reason to move/clone things like ChatZilla or Venkman.

-- 
James Ross <silver@warwickcompsoc.co.uk>
ChatZilla and Venkman Developer

And on the seventh day brendan@mozilla.org spoke:

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

Benjamin said in <18ednY5TPuAqXpbbnZ2dnUVZ_rqhnZ2d@mozilla.org>, that it
will be ok to break other apps and not fix the breakage.

How will that improve the lives of all XUL apps from mozilla.org aside
from Firefox?

That is a major worsening for those apps (at least the ones, who lived in
cvs.mozilla.org), because until now, you could happily develop the code
on your app and not care about the core very much.

How can you say, that I make a "feelings" sort of judgement, when it is
totally obvious, that you are moving the 2nd tier (Thunderbird) and 3rd
tier apps (Seamonkey, Camino, Sunbird) in cvs.mozilla.org to the same
state as apps outside of mozilla.org?

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

I have a university degree in economics, so I believe that I very well
understand the economic realities here.

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

I don't think that it is unreasonable to ask for a continuation of the
current situation (one repository) and not accept a serious degradation
in terms of effort needed to build and to maintain your app and Robert
has also brought up some very good arguments.

But if it is totally unreasonable to ask for the inclusion of /calendar
from day one, then please at least post a clear and concise roadmap
detailing your plans to add additional apps to the repository in due time
(let's say in 6 months) and a clear and concise plan when the tree rules
will return to their former state.

That would at least partly allay my doubts.

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

I would already be content if the caring would stay the same and not
degrade.

Simon
-- 
Sunbird/Lightning Website Maintainer:
http://www.mozilla.org/projects/calendar
Sunbird/Lightning blog: http://weblogs.mozillazine.org/calendar

Simon Paquet wrote:

> That is a major worsening for those apps (at least the ones, who lived in
> cvs.mozilla.org), because until now, you could happily develop the code
> on your app and not care about the core very much.

Why do you think that is going to change? If anything it should improve,
since you can build the app on a pre-built or stable xulrunner core.

> But if it is totally unreasonable to ask for the inclusion of /calendar
> from day one, then please at least post a clear and concise roadmap
> detailing your plans to add additional apps to the repository in due time
> (let's say in 6 months) and a clear and concise plan when the tree rules
> will return to their former state.

The plan is for calendar (+ seamonkey/camino) to remain in other
repositories permanently. This is a continuation of the clear separation of
the platform and applications and building on a common XULRunner core.

--BDS

On Mar 30, 10:47 am, Simon Paquet <s...@gmx.de> wrote:
> Benjamin said in <18ednY5TPuAqXpbbnZ2dnUVZ_rqhn...@mozilla.org>, that it
> will be ok to break other apps and not fix the breakage.

It will be ok to change APIs incompatibly for Mozilla 2, absolutely.

Already it's ok to change APIs and leave it to non-tier-1 tinderboxed
products to fix, or negotiate otherwise. Is this not the case with
calendar apps, or are they using so stable a set of APIs that it just
doesn't happen?

Anyway, APIs will change incompatibly for Mozilla 2 and we will not
try to coordinate simultaenous changes to all API clients hosted in
cvs.mozilla.org. You can count on that. I hope you can see why that
would be fatal to the whole effort.

> How will that improve the lives of all XUL apps from mozilla.org aside
> from Firefox?

Because we will interact at a gentler pace to consolidate the
necessary better APIs and cast them in supportable forms. Which is not
the case with today's APIs, some of which are not frozen, and many of
which have design flaws that haunt us.

> That is a major worsening for those apps (at least the ones, who lived in
> cvs.mozilla.org), because until now, you could happily develop the code
> on your app and not care about the core very much.

Benjamin addressed this already. You are reversing the arrow of
breakage, and again assuming that today's core APIs (the ones you care
about) do not change. This may be true for 1.x milestones, because we
maintain API compat pretty carefully. It won't be true for Mozilla 2.

And as James Ross points out, until you are ready to port to Mozilla
2, or participate in API evolution and negotiation, you should not
care about the core very much.

> How can you say, that I make a "feelings" sort of judgement, when it is
> totally obvious, that you are moving the 2nd tier (Thunderbird) and 3rd
> tier apps (Seamonkey, Camino, Sunbird) in cvs.mozilla.org to the same
> state as apps outside of mozilla.org?

A lower tier means breaking changes should be avoided, but they're
allowed. Turning a tier-2 or lower tinderbox red does not close the
tree.

And I cited Joost, et al., to make the point that being hosted in
cvs.mozilla.org does not make one immune from breakage, *or* mean apps
hosted elsewhere can be broken. For Mozilla 1.x, we take API compat
(too) seriously. For Mozilla 2, we will make better APIs where they
pay off, and the "breakage" will be worth it for apps that port to the
better Mozilla 2 APIs.

The only difference in where app source is hosted, given the fact that
most apps are tier-2, is the coordination cost reduction we require in
order to evolve Mozilla 2 APIs and the code behind the APIs.

> >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.
>
> I have a university degree in economics, so I believe that I very well
> understand the economic realities here.

Excellent. Why do you want a free lunch, or do you think we owe every
XUL app one? If you believe every cvs.m.o-hosted app gets the free
lunch of never being broken by API changes, then you're already
disagreeing with existing tinderbox tier-based policy.

What's more, and here is the economic argument: we cannot do Mozilla 2
and keep all apps working all the time. That's my settled judgment, we
can argue about it based on more detailed analyses and propositions.
But I'll be surprised if you disagree.

> I don't think that it is unreasonable to ask for a continuation of the
> current situation (one repository) and not accept a serious degradation
> in terms of effort needed to build and to maintain your app and Robert
> has also brought up some very good arguments.

I'm not sure what Robert's position is now, but let's leave that to
other links in this thread.

Since Mozilla 2 will break API compatibility, we are arguing about
whether it is desirable to keep all currently source-hosted apps
working all the time. I say it's not, both because it is fatal to
Mozilla 2's quality and time to completion, and to better APIs and
modularity that benefit those apps and others (Joost, etc.).

> But if it is totally unreasonable to ask for the inclusion of /calendar
> from day one, then please at least post a clear and concise roadmap
> detailing your plans to add additional apps to the repository in due time
> (let's say in 6 months) and a clear and concise plan when the tree rules
> will return to their former state.

As Benjamin said, never. Repositories are not the same as tinderboxes
and tier-based policies. Hosting does not guarantee no-API-breaks, but
it can beget code entanglements, and it does harm first-pull and
source-code-size approachability. It definitely will derail Mozilla 2
to have to keep all currently-cvs-hosted XUL apps working, for quite a
while. When Mozilla 2 is "done", then the other objections
(approachability, entanglement hazards) still stand, even if the APIs
are frozen and sufficient for the other XUL apps that currently live
in cvs.m.o.

The new world is more decoupled, both branch-wise as sayrer points out
(you don't need drivers and build resources to cut a branch), and in
terms of dependent projects.

But since you think the current cvs.m.o hosting gives calendar some
guarantees that I think arise *only* from our Mozilla 1.x API
compatibility promise, then perhaps you can correct that premise and
agree that for Mozilla 2, where APIs will change incompatibly, it's
not in calendar's interest (or Mozilla 2's) to be co-hosted in the new
repository.

> I would already be content if the caring would stay the same and not
> degrade.

As I keep repeating, "caring" is easier and more effective with better
APIs, which we must evolve toward with more focus and fewer initial
and day-to-day constraints. You really are not as cared for as you
seem to think in the current setting, just because you have hosting at
cvs.m.o.

/be

On 3/29/07, Robert Kaiser <kairo@kairo.at> wrote:
> Benjamin Smedberg schrieb:
> > 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.
>
> OK, I just hope that without having Firefox using that same approach
> this client.mk-style solution will be cared about enough, as the project
> I (obviously) care about most will need to use that quite heavily ;-)

If

a) SeaMonkey, Calendar, Camino, Thunderbird and other "multi-pull.mk"
consumers have active development communities; and
b) the quality of multi-pull.mk is important to those projects, then

why would that solution not be "cared about" enough?  Are you saying
"I hope that someone other than me will maintain it for my benefit",
in the manner of Brendan's proposed free lunch, or am I missing
something?

I'm not hearing anyone here saying "this is important to my
non-Firefox project, how can I help keep that project in sync as
needed?", which surprises me given that it's apparently a direct
threat to the survival of significant communities!

Keep in mind that projects which wish to stay with Mozilla 1.x
wouldn't, I'm pretty sure, have to move away from CVS at all.  Many of
us certainly believe that other projects will want to take advantage
of the Mozilla 2 stuff, and we will endeavour to support those other
projects in the design and implementation of it, but if a temporarily
split repository is too costly, those projects shouldn't be forced to
bear it.

Mike

brendan@mozilla.org wrote:
> A lower tier means breaking changes should be avoided, but they're
> allowed. Turning a tier-2 or lower tinderbox red does not close the
> tree.

That's currently false, depending on what you mean by "tier-2".  As the Firefox 
tinderbox says:  "All checkins must not break SeaMonkey or Thunderbird on the 
tier 1 platforms."

> What's more, and here is the economic argument: we cannot do Mozilla 2
> and keep all apps working all the time.

Absolutely.  I do think, however that after the initial phase of the project, 
once the APIs stabilize somewhat, we should be able to get to a point where we 
have a policy similar to the current one.  As I see it, the relevant features of 
that policy are:

1)  Core API changes involve an lxr search and fixing of consumers where easy or 
filing of bugs where difficult.

2)  Sending certain non-Firefox tinderboxen (e.g. Thunderbird) red by a core 
API-change checkin is not acceptable.

Note that I agree that we can't maintain that state of things during the entire 
Mozilla 2 effort.  I do think that we should get Mozilla 2 to a state where we 
can do that for our main apps (Firefox and Thunderbird at least).  Given how 
little of the code in our other apps (editor being a major exception) is C++, 
that should be sufficient to prevent serious issues for other apps as well.

All this is completely orthogonal to how many repositories we have; all we need 
is a search that searches them all and a way to pull them easily to fix things 
as needed.  We have all of that already on top of CVS (with lxr and 
MOZ_CO_PROJECT); I doubt it would be that difficult to do it over whatever VCS 
we end up with.

> Since Mozilla 2 will break API compatibility, we are arguing about
> whether it is desirable to keep all currently source-hosted apps
> working all the time.

I think the question is whether Mozilla 2 will at some point get to a state 
where it's desirable to keep those apps (or some subset of them) working all the 
time.  I claim yes.  We _want_ trunk Thunderbird users to be using a trunk core 
so we don't suddenly have to revisit editor changes months later when 
Thunderbird finally switches to a "beta" core.  That sort of thing.  Again, I 
agree that doing that in the short term is undesirable.

Put another way: if we have a core component, we need an app that actually 
exercises that component and is being used if we're going to test it in a 
serious way.  Long-term, that is.  If we have no such apps, we should reconsider 
the existence of that component, perhaps.  ;)

> Hosting does not guarantee no-API-breaks, but
> it can beget code entanglements, and it does harm first-pull

With MOZ_CO_PROJECT that's not actually true.  But again, I don't care about the 
exact set of repositories; I care about what people do with them.

-Boris

Boris Zbarsky wrote:

> Given how little of the code in our other apps (editor being a major 
> exception) is C++

Actually there's no C++ editor code in our apps, it's all in core. For 
instance, SeaMonkey has very little C++ code that's not in either 
Firefox or Thunderbird (and will have even less as a MOZ_XUL_APP app). 
History and bookmarks are the obvious counterexamples.

-- 
Warning: May contain traces of nuts.

brendan@mozilla.org wrote:

> But since you think the current cvs.m.o hosting gives calendar some
> guarantees that I think arise *only* from our Mozilla 1.x API
> compatibility promise, then perhaps you can correct that premise and

FWIW, we do not make any promises to calendar right now. The tinderbox rules
state that changes must not break Firefox, Thunderbird, or SeaMonkey on the
tier-1 platforms. I have and will continue to break Camino and calendar if
necessary.

--BDS

Boris Zbarsky wrote:

> I think the question is whether Mozilla 2 will at some point get to a
> state where it's desirable to keep those apps (or some subset of them)
> working all the time.  I claim yes.  We _want_ trunk Thunderbird users
> to be using a trunk core so we don't suddenly have to revisit editor
> changes months later when Thunderbird finally switches to a "beta"
> core.  That sort of thing.  Again, I agree that doing that in the short
> term is undesirable.

Yes, I think it's desirable for Thunderbird to use trunk gecko. But I
disagree that should be a necessity for making changes to gecko/firefox
going forward. I feel this especially as I'm making build system changes
now: I end up having to build three apps in multiple configurations
(static/dynamic) on three platforms: that is very painful, and if I *do*
break tbird it can be very difficult (or at times impossible) to fix it
without painstaking effort.

> Put another way: if we have a core component, we need an app that
> actually exercises that component and is being used if we're going to
> test it in a serious way.  Long-term, that is.  If we have no such apps,
> we should reconsider the existence of that component, perhaps.  ;)

Absolutely. Or we should at least have well defined automated testsuites. We
are swinging a hatchet at features, especially any that are not used by Firefox.

For that matter, I've argued that apps should not be using binary
"components" in the XPCOM sense at all: that the primary APIs of mozilla2
will be managed APIs (JS2), and that we should expose a ctypes API for apps
to interface with external libraries.

--BDS

Neil wrote:
> Actually there's no C++ editor code in our apps, it's all in core.

I mean the C++ parts of editor itself (a lot of which can be disabled).

-Boris

Benjamin Smedberg wrote:
> Yes, I think it's desirable for Thunderbird to use trunk gecko. But I
> disagree that should be a necessity for making changes to gecko/firefox
> going forward. I feel this especially as I'm making build system changes
> now: I end up having to build three apps in multiple configurations
> (static/dynamic) on three platforms: that is very painful, and if I *do*
> break tbird it can be very difficult (or at times impossible) to fix it
> without painstaking effort.

I can see how that could be a problem with the build system, yes.  At the same 
time, layout API changes are something that's usually pretty easy to fix across 
the board.  And embedding API changes are something we WANT to fix across the board.

Perhaps we should refocus on not worrying so much about absolutes ("must always 
fix X" or "never worry about Y") and instead worry about the typical types of 
changes we want to make and what apps one should worry about (either by fixing 
them or by giving their authors fair warning ahead of time) when making those 
changes.

Note that the "fair warning" approach scales well to non-mozilla.org apps too, 
if people actually do it (via newsgroup posts, etc).  The problem is figuring 
out where to make such announcements.

>> Put another way: if we have a core component, we need an app that
>> actually exercises that component and is being used if we're going to
>> test it in a serious way.  Long-term, that is.  If we have no such apps,
>> we should reconsider the existence of that component, perhaps.  ;)
> 
> Absolutely. Or we should at least have well defined automated testsuites.

We should have those too, but they have some serious limitations.  Most 
saliently, none of them actually test what the user sees, and all our apps are 
pretty focused on showing the user stuff (webpages, e-mail, whatever).

> We are swinging a hatchet at features, especially any that are not used by Firefox.

I'm not convinced that's the right attitude; if it is, why bother with a 
platform at all?  We've had lots of core features that were not used by Firefox 
but now are as people write extensions and new Firefox features...

We should remove features if they're not useful, sure.  But "useful" and 
"currently used by Firefox" are very different things.

> For that matter, I've argued that apps should not be using binary
> "components" in the XPCOM sense at all  that the primary APIs of mozilla2 will be managed APIs (JS2), and that we 
should expose a ctypes API for apps
> to interface with external libraries.

So basically give necko a non-XPCOM API so mailnews can work and so forth?  Why 
is that worth the effort given that XPCOM exists?

-Boris

Boris Zbarsky wrote:

> So basically give necko a non-XPCOM API so mailnews can work and so
> forth?  Why is that worth the effort given that XPCOM exists?

No, a JS2 API (in the case of necko, probably quite similar to the existing
API). There would be no binary APIs exposed by our platform at all.

--BDS

Benjamin Smedberg wrote:
> No, a JS2 API (in the case of necko, probably quite similar to the existing
> API). There would be no binary APIs exposed by our platform at all.

So wait.  Necko needs binary code to perform its network access (its channel 
impls, etc).  Our core code needs to talk to said mailnews channel impls. 
You're saying the right way to move bytes from a mail server into a docshell is 
through JS2?

-Boris

Boris Zbarsky wrote:
> So wait.  Necko needs binary code to perform its network access (its 
> channel impls, etc).  Our core code needs to talk to said mailnews 
> channel impls. You're saying the right way to move bytes from a mail 
> server into a docshell is through JS2?

Or put another way, how does an app author implement a protocol handler with 
performance that's not significantly worse than, say, what HTTP has?

-Boris

Boris Zbarsky wrote:
> Benjamin Smedberg wrote:
>> No, a JS2 API (in the case of necko, probably quite similar to the
>> existing
>> API). There would be no binary APIs exposed by our platform at all.
> 
> So wait.  Necko needs binary code to perform its network access (its
> channel impls, etc).  Our core code needs to talk to said mailnews
> channel impls. You're saying the right way to move bytes from a mail
> server into a docshell is through JS2?

Yes, I expect that there will be a JS2 type that can efficiently wrap binary
data (kinda like ACString currently) and pass it around without significant
conversion overhead. Necko exposes the socket APIs already.

--BDS

Benjamin Smedberg wrote:
> Yes, I expect that there will be a JS2 type that can efficiently wrap binary
> data (kinda like ACString currently)

I wouldn't exactly call ACString efficient.... or rather our CString 
implementation of it is not particularly efficient.  ACString per se could be 
not too bad, if you seriously allowed multi-fragment strings, etc (which is what 
you need to efficiently replace nsIInput/OutputStream with Read/WriteSegments).

One other concern here is who's going to do all this, by the way.  Mailnews was 
never even fully ported to necko (from netlib).  I don't see it being quickly 
ported to some other new API...

Put another way, I was under the impression that we were NOT going for another 
"rewrite the world like in 1998" kind of thing here, but were only going to 
break API compat where it was needed and where it would help significantly.  Was 
this an incorrect impression?  If not, why is the proposed change needed and 
what would it significantly help?

-Boris

Benjamin Smedberg wrote:
> Boris Zbarsky wrote:
> 
>> I think the question is whether Mozilla 2 will at some point get to a
>> state where it's desirable to keep those apps (or some subset of them)
>> working all the time.  I claim yes.  We _want_ trunk Thunderbird users
>> to be using a trunk core so we don't suddenly have to revisit editor
>> changes months later when Thunderbird finally switches to a "beta"
>> core.  That sort of thing.  Again, I agree that doing that in the short
>> term is undesirable.
> 
> Yes, I think it's desirable for Thunderbird to use trunk gecko. But I
> disagree that should be a necessity for making changes to gecko/firefox
> going forward. I feel this especially as I'm making build system changes
> now: I end up having to build three apps in multiple configurations
> (static/dynamic) on three platforms: that is very painful, and if I *do*
> break tbird it can be very difficult (or at times impossible) to fix it
> without painstaking effort.
> 

Just to clarify here, did you say that you would like to leave 
Thunderbird with build problems that are impossible to fix?

Axel

Boris Zbarsky schrieb:
> Note that I agree that we can't maintain that state of things during the 
> entire Mozilla 2 effort.  I do think that we should get Mozilla 2 to a 
> state where we can do that for our main apps (Firefox and Thunderbird at 
> least).  Given how little of the code in our other apps (editor being a 
> major exception) is C++, that should be sufficient to prevent serious 
> issues for other apps as well.
> 
> All this is completely orthogonal to how many repositories we have; all 
> we need is a search that searches them all and a way to pull them easily 
> to fix things as needed.  We have all of that already on top of CVS 
> (with lxr and MOZ_CO_PROJECT); I doubt it would be that difficult to do 
> it over whatever VCS we end up with.

I'm with Boris on that. Reshaping stuff for Mozilla2 means breaking old 
APIs, sure, that's the point of it all, right? So, of course, that's OK. 
Also first getting this into (basic) shape without caring about a 
plethora of other apps is OK.

I care about 2 things though:
1) From my experience, core APIs used by Firefox only often needs 
improvements to be used by other, possibly non-browser-based apps. So we 
need to pull some of those into Mozilla2 development early enough that 
we can fix APIs in a way that helps everyone. Note that the current 
mozilla.org-hosted projects (Thunderbird, SeaMonkey, Sunbird, Camino, 
Minimo) are usually a good base set of non-Firefox apps to test those 
APIs against.
2) The base infrastructure for pulling multiple repositories, pulling 
them together and build against our trunk core/XULRunner should be an 
integrated part of the build infrastructure, so that everyone's using a 
common base and people working on refining core APIs to work better with 
non-Firefox apps (see 1) have an easy and common way to pull the source 
for other mozilla.org projects (just like MOZ_CO_PROJECT currently).

Additionally, I trust that mozilla.org will still be hosting 
repositories for non-Firefox projects, so we need some common rules and 
infrastructure or people maintaining those repositories and/or the 
machines they're running on will get confused and grumpy soon enough ;-)

Robert Kaiser

Axel Hecht wrote:

> Just to clarify here, did you say that you would like to leave
> Thunderbird with build problems that are impossible to fix?

No, but I think it's possible that we will end up in that situation unless a
much larger community that can hack mailnews appears.

--BDS

And on the seventh day Benjamin Smedberg spoke:

>> Just to clarify here, did you say that you would like to leave
>> Thunderbird with build problems that are impossible to fix?
>
>No, but I think it's possible that we will end up in that situation unless a
>much larger community that can hack mailnews appears.

So MoCo is essentially abandoning its second product (Thunderbird) in
favor of Firefox?

Interesting...

Simon
-- 
Sunbird/Lightning Website Maintainer:
http://www.mozilla.org/projects/calendar
Sunbird/Lightning blog: http://weblogs.mozillazine.org/calendar

On Mar 30, 8:26 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
> Benjamin Smedberg wrote:
> Put another way, I was under the impression that we were NOT going for another
> "rewrite the world like in 1998" kind of thing here, but were only going to
> break API compat where it was needed and where it would help significantly.

Your impression is correct. I've said we are not going to kill XPCOM
in Mozilla 2, but Benjamin may have hopes. It's too early to get too
worried about this, except that since we haven't integrated Tamarin
yet, let alone cut the initial repository, I *do* think Benjamin's
statements are premature. We should have a separate thread with some
measurements to back up opinions, later, about all of this ctypes vs.
XPCOM vs. JS2 stuff.

/be

On Mar 31, 7:40 am, Simon Paquet <s...@gmx.de> wrote:
> And on the seventh day Benjamin Smedberg spoke:
>
> >> Just to clarify here, did you say that you would like to leave
> >> Thunderbird with build problems that are impossible to fix?
>
> >No, but I think it's possible that we will end up in that situation unless a
> >much larger community that can hack mailnews appears.
>
> So MoCo is essentially abandoning its second product (Thunderbird) in
> favor of Firefox?

Yikes. You just twisted what Benjamin actually wrote into something
completely different. Benjamin wrote "it's possible that we will end
up with [Thunderbird build support costing Benjamin and the few others
who work on the build system way too much]" and you take that as "MoCo
is abandoning Thunderbird."

Do you not see the difference? I'm having a hard time believing this
was an innocent misreading.

Firefox >> Thunderbird. This isn't a "MoCo" thing, it's a fact that's
obvious based on active user counts, buzz, effect on the competition,
effect on the web, etc. etc.

This does *not* mean that only Firefox matters, or that other XUL apps
must be broken all the time. But without a Mozilla 2 that focuses on
APIs and embedding, where "focuses" means "does not have to keep all
current API clients hosted in cvs.m.o working at all times, or even
for a long stretch up front", then everyone will face rising costs,
conflicts over bad APIs, and build system divergence.

Here's my own controversial opinion. Please don't lay it at the feet
of "MoCo" and act as if you are discerning some Evil Plot against
other XUL apps:

The best thing that could happen for Thunderbird would be to grow the
larger community that Benjamin believes will be needed to keep its
build system converged with the base XULRunner/Firefox one, and do
other things such as calendar integration. That effort should be done
in as focused and open-source a way as possible, which is not the case
so long as "MoCo" is paying for almost all active Thunderbird dev/
build/QA. Without such a community, Thunderbird will suffer rising
costs to everyone (not just to "MoCo") relative to benefits to its
users.

You might argue that "MoCo" should throw *more* money at Thunderbird.
That would inevitably mean less focus and fewer people working on
Firefox and the core Gecko/XULRunner code. Yet it would also make
Thunderbird even less of an open source project with significant patch
inflow from various committers, calendar integration to rival Outlook,
etc. I believe it would help kill Thunderbird better than any
alternative.

Don't take this to mean that money is the issue. As a board member of
Mozilla Foundation, I'm happy to spend on Thunderbird *if* there's a
plan and signs of a community that will develop it to the degree that
it needs to be developed, and in different-in-kind ways, all while
keeping its build system from diverging. Money alone won't provide
these things, and money spent badly would actually harm Thunderbird.

I spoke to a reporter when I was at SXSW, a savvy guy. He is a Mozilla
fan and has used Thunderbird, and caused his company to use it, for
years. His company is now switching to Outlook for want of calendar
integration. It's not too late for a reversal here, but the plain fact
is that Thunderbird is not going to grow and fly free as it should
while it is subsidized and maintained by too few developers.

End personal opinion.

Reactions?

/be

Boris Zbarsky wrote:

> Put another way, I was under the impression that we were NOT going for
> another "rewrite the world like in 1998" kind of thing here, but were
> only going to break API compat where it was needed and where it would
> help significantly.  Was this an incorrect impression?  If not, why is
> the proposed change needed and what would it significantly help?

My proposal was mainly focused on the fact that we now have the opportunity
to break binary compatibility with XPCOM, and have several very good reasons
to do so:

1) add cycle-collection, weak-reference, and possibly getinterface goop to
the root nsISupports interface

1a) or even make all "XPCOM" objects implement a MMGc root (brendan pointed
out this was hard for objects that could be multithreaded)

1b) or even, if all "xpcom" binary objects live in the same shared library,
use C++ dynamic casts instead of QI

2) replace out parameters with nsCOMPtr<>&

3) replace nsresults with real return values and use exceptions

#1 could be accomplished without significant code-level changes

#2 and #3 could possibly be achieved through automatic code rewriting
(though we don't know yet how well that will work), and can happen
incrementally.

I'm not saying we should "rewrite XPCOM" from the ground up. Rather that we
can make changes to the existing framework that are radical, without
requiring everyone to rewrite everything. And that we should seriously
consider making the "JS2 API" the thing we freeze in the future, and should
not re-freeze XPCOM interfaces.

--BDS

On Mar 30, 4:48 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
> bren...@mozilla.org wrote:
> > A lower tier means breaking changes should be avoided, but they're
> > allowed. Turning a tier-2 or lower tinderbox red does not close the
> > tree.
>
> That's currently false, depending on what you mean by "tier-2".

Sorry for the abuse of "tier" to mean something other than tinderbox
platform tier.

> As the Firefox
> tinderbox says:  "All checkins must not break SeaMonkey or Thunderbird on the
> tier 1 platforms."

Yeah, that's the group of projects -- Firefox, SeaMonkey and
Thunderbird -- that I meant to distinguish from "tier-2" projects. For
Mozilla 2, I'm saying that we make the equivalent initial group be
Firefox and XULRunner.

> Absolutely.  I do think, however that after the initial phase of the project,
> once the APIs stabilize somewhat, we should be able to get to a point where we
> have a policy similar to the current one.

I agree so long as the XULRunner-based app is well-owned. There will
be more than one such app, some commercial and not all open source. We
won't just "not care" about all but the designated turn-it-red-close-
the-tree one, but we need an exemplar and it needs to be all open
source.

> As I see it, the relevant features of
> that policy are:
>
> 1)  Core API changes involve an lxr search and fixing of consumers where easy or
> filing of bugs where difficult.
>
> 2)  Sending certain non-Firefox tinderboxen (e.g. Thunderbird) red by a core
> API-change checkin is not acceptable.
>
> Note that I agree that we can't maintain that state of things during the entire
> Mozilla 2 effort.  I do think that we should get Mozilla 2 to a state where we
> can do that for our main apps (Firefox and Thunderbird at least).  Given how
> little of the code in our other apps (editor being a major exception) is C++,
> that should be sufficient to prevent serious issues for other apps as well.

I agree in principle, and I hope Thunderbird is XULRunner-based in the
right time frame, but no one has signed up for that. I'm not, and I
don't think my lack of serving that lunch should delay Mozilla 2
initial repository population or early bottom-up development, so....

> I think the question is whether Mozilla 2 will at some point get to a state
> where it's desirable to keep those apps (or some subset of them) working all the
> time.  I claim yes.

It depends on the number and kind of APIs.

I used to be a kernel hacker. We kept thousands of apps working across
major kernel rearchitecture at SGI, but not "all at once". "All at
once" is different from "all the time." I'm using "at once" to connote
the continuous integration of tinderboxes, and the turn-it-red-close-
the-tree rule.

If you have a hundred API entry points (think Unix kernel of old;
several hundred now, I'm sure, plus device driver APIs, and later
virtual filesystem APIs), the subset of apps you try not to break can
be large, but it won't be tested fully except over long pre-release
cycles. So not "all at once". Any kernel change that does not mess
with standard header files will not cause compile-time errors for
apps, so no red tree worries.

With thousands of APIs with shared memory data structures, C++ types,
etc., scattered (and this is a bug!) across the source tree, it's a
different story. Not only won't you get test significant test
coverage, you'll find that different API consumers disagree on the
meaning of a given API. Hashing this out takes time and some amount of
back-and-forth, what I've called "API negotiation". It may involve
proving and fixing a bug in the API consumer, API producer, or both.
It's a significant challenge.

For Mozilla 2, we want fewer, better defined embedding and app-support
APIs. I mean fewer than all the ones exported from currently buildable
DLLs/DSOs here, not just the ones marked @status FROZEN or otherwise
"public". We also want better programming languages, which include JS2
and XBL2. These are "APIs" in the best sense, and they enable APIs at
higher levels of discourse, with better compatibility provision
(forward and backward).

Ok, fine aspirations, you say. What does this mean? I'm not going to
promise the moon, but I think we can get to a better condition for all
XUL apps, however hosted, in the Mozilla 2 milestone. But not if we
make the subset too big, too soon. And it's way too soon to be adding
to the proposed Firefox + XULRunner group for the Mozilla 2
repository, which is the topic of this post.

> We _want_ trunk Thunderbird users to be using a trunk core
> so we don't suddenly have to revisit editor changes months later when
> Thunderbird finally switches to a "beta" core.  That sort of thing.  Again, I
> agree that doing that in the short term is undesirable.

Great, I think we still agree.

> Put another way: if we have a core component, we need an app that actually
> exercises that component and is being used if we're going to test it in a
> serious way.  Long-term, that is.  If we have no such apps, we should reconsider
> the existence of that component, perhaps.  ;)

Not "perhaps", *definitely* and as a matter of regularly enforced
policy. We've always tried to reduce attack surface, and for Mozilla 2
we will move out deadwood even more aggressively. Gopher's on the
chopping block!

> > Hosting does not guarantee no-API-breaks, but
> > it can beget code entanglements, and it does harm first-pull
>
> With MOZ_CO_PROJECT that's not actually true.

By "that's not true" you mean just the last point, "first-pull"
approachability.

But I claim the cvs.mozilla.org repository size and (related)
organization *does* harm approachability, and there's lots of messy
human-based evidence for this.

One competing example is webkit.org. Now, I don't think webkit.org
should be our model, since the only truly significant app that uses it
(sorry, Nokia) is Safari, which is closed source, and I believe Apple
gets its way with webkit.org if Safari needs it, more than Firefox
rightly rules the Gecko roost. So I can't evaluate how well webkit.org
serves multiple apps, except to note that it's being embedded by Adobe
and other companines and individuals than Nokia.

Webkit is certainly a smaller unit than our minimal back-end module-
set, not only more approachable but with fewer and "flatter" APIs. We
should definitely compete with it at the right layer of our onion.

But (back on topic) I want our hosted-as-Mozilla-2 onion to be smaller
than today's cvs.m.o, even if it's not as small as webkit.org. It
should build Firefox and XULRunner along with the embeddable Gecko.

I agree we may end up with another XUL app hosted in the new
repository, but I do not agree that we must host a second XUL app. It
may be better that way, but it may not. We'll have to find out after
some amount of Mozilla 2 work has been done, and before that, I don't
want to pre-judge it. Thunderbird, if it switches to XULRunner and has
a community to carry it in the Mozilla 2 repository, is certainly a
candidate. But note all the "Ifs" in that sentence. We cannot hold up
Mozilla 2 or the Firefox/XULRunner future on those contingencies.

/be

brendan@mozilla.org wrote:
> On Mar 31, 7:40 am, Simon Paquet <s...@gmx.de> wrote:
>> And on the seventh day Benjamin Smedberg spoke:
>>
>>>> Just to clarify here, did you say that you would like to leave
>>>> Thunderbird with build problems that are impossible to fix?
>>> No, but I think it's possible that we will end up in that situation unless a
>>> much larger community that can hack mailnews appears.
>> So MoCo is essentially abandoning its second product (Thunderbird) in
>> favor of Firefox?
> 
> Yikes. You just twisted what Benjamin actually wrote into something
> completely different. Benjamin wrote "it's possible that we will end
> up with [Thunderbird build support costing Benjamin and the few others
> who work on the build system way too much]" and you take that as "MoCo
> is abandoning Thunderbird."
> 
> Do you not see the difference? I'm having a hard time believing this
> was an innocent misreading.
> 
> Firefox >> Thunderbird. This isn't a "MoCo" thing, it's a fact that's
> obvious based on active user counts, buzz, effect on the competition,
> effect on the web, etc. etc.
> 
> This does *not* mean that only Firefox matters, or that other XUL apps
> must be broken all the time. But without a Mozilla 2 that focuses on
> APIs and embedding, where "focuses" means "does not have to keep all
> current API clients hosted in cvs.m.o working at all times, or even
> for a long stretch up front", then everyone will face rising costs,
> conflicts over bad APIs, and build system divergence.
> 
> Here's my own controversial opinion. Please don't lay it at the feet
> of "MoCo" and act as if you are discerning some Evil Plot against
> other XUL apps:
> 
> The best thing that could happen for Thunderbird would be to grow the
> larger community that Benjamin believes will be needed to keep its
> build system converged with the base XULRunner/Firefox one, and do
> other things such as calendar integration. That effort should be done
> in as focused and open-source a way as possible, which is not the case
> so long as "MoCo" is paying for almost all active Thunderbird dev/
> build/QA. Without such a community, Thunderbird will suffer rising
> costs to everyone (not just to "MoCo") relative to benefits to its
> users.
> 
> You might argue that "MoCo" should throw *more* money at Thunderbird.
> That would inevitably mean less focus and fewer people working on
> Firefox and the core Gecko/XULRunner code. Yet it would also make
> Thunderbird even less of an open source project with significant patch
> inflow from various committers, calendar integration to rival Outlook,
> etc. I believe it would help kill Thunderbird better than any
> alternative.
> 
> Don't take this to mean that money is the issue. As a board member of
> Mozilla Foundation, I'm happy to spend on Thunderbird *if* there's a
> plan and signs of a community that will develop it to the degree that
> it needs to be developed, and in different-in-kind ways, all while
> keeping its build system from diverging. Money alone won't provide
> these things, and money spent badly would actually harm Thunderbird.
> 
> I spoke to a reporter when I was at SXSW, a savvy guy. He is a Mozilla
> fan and has used Thunderbird, and caused his company to use it, for
> years. His company is now switching to Outlook for want of calendar
> integration. It's not too late for a reversal here, but the plain fact
> is that Thunderbird is not going to grow and fly free as it should
> while it is subsidized and maintained by too few developers.
> 
> End personal opinion.
> 
> Reactions?

My personal view is that Thunderbird as an application is doing much 
better outside the US, and that Mozilla as an open source effort is 
doing much worse outside the US. That doesn't mix very well, sadly. 
There are other problems like extension installation weirdness, which 
makes Thunderbird less agile as a project.

Neither Mail.app nor Outlook nor webmail are an option for me, so let's 
try I'll take a step back and look at the fundamentals.

My axiomatic base of arguments is "the Mozilla ecosystem matters, not 
js2 nor xpcom". And by "ecosystem", I mean all of its current diversity, 
from Firefox to undisclosed business apps. We will see a time where 
kicking Firefox is needed, giving it a new sibling that's able to take 
the web further than Firefox can. Our ability to do that will severly 
depend on the diversity of our ecosystem then.

Now, I do see a good case for not keeping all of the Mozilla ecosystem 
up and concurrent while kicking Mozilla to Mozilla2, and I do agree that 
Firefox is likely the app to test the outcome.

Yet, our ecosystem depends on features not exposed in Firefox, and while 
we don't migrate everything over ourselves, the acceptance of Mozilla2 
will depend on those spear-heading that effort to guide the way for our 
ecosystem to migrate.

We didn't hear enough so far about how the Mozilla2 team intends to deal 
  with this. Boris mentioned editing already. We just love to regress 
that already, so, how do we test it if not in Thunderbird? Are there 
other architecture aspects that need a migration path? What about 
massive tool-generated patches? Are those going to come with a recipe to 
reproduce them for apps that are not included in the initial landing?

While I do follow the argument that the Mozilla2 team should not migrate 
every app and interface out there, I do think that it's the 
responsibility of that team to pave the road for migration, and to drive 
testing enviroments for particular features that need to be kept alive 
outside of what Firefox currently does. Not sure if there's a whole lot 
more than editing here, the ecosystem would know.

Axel

brendan@mozilla.org schrieb:
> Without such a community, Thunderbird will suffer rising
> costs to everyone (not just to "MoCo") relative to benefits to its
> users.

The interesting thing here is that the SeaMonkey development community 
seems to be more active and vibrant than the Thunderbird community at 
the moment. The good thing with that is that Thunderbird profits from 
the work we're doing on the mailnews side as well, and we can work 
together with Thunderbird people to improve all our lives.

I hope we can manage some current challenges of the mailnews code (esp. 
completing the toolkit conversion) together in cooperation of both 
projects sharing that backend code.

That's the positive side of our community ecosystem. :)

But it also tends to lead a bit off-topic here...

Robert Kaiser

brendan@mozilla.org wrote:
> Yeah, that's the group of projects -- Firefox, SeaMonkey and
> Thunderbird -- that I meant to distinguish from "tier-2" projects. For
> Mozilla 2, I'm saying that we make the equivalent initial group be
> Firefox and XULRunner.

Like I said, as an initial group that makes perfect sense.  Longer-term, we 
reevaluate.  Some of Benjamin's comments made me worry about that "reevaluate" 
step.  ;)

>> Absolutely.  I do think, however that after the initial phase of the project,
>> once the APIs stabilize somewhat, we should be able to get to a point where we
>> have a policy similar to the current one.
> 
> I agree so long as the XULRunner-based app is well-owned.

Of course.  I don't think anyone is suggesting holding the tree hostage to 
not-well-owned apps (hello, XMLTerm!).

> We won't just "not care" about all but the designated turn-it-red-close-
> the-tree one

Perfect.

> I agree in principle, and I hope Thunderbird is XULRunner-based in the
> right time frame, but no one has signed up for that.

I see no problem with having "based on XULRunner" as a prerequisite for apps to 
be considered for includes in the "red means you must fix" rule.  In fact, that 
sounds quite good.

If it turns out that writing apps on top of XULRunner is too difficult, then 
we'll need to fix XULRunner, of course.  But I doubt this will be an issue.

> I'm not, and I don't think my lack of serving that lunch should delay Mozilla 2
> initial repository population or early bottom-up development, so....

I don't think _anything_ should delay the initial setup and early development. 
I'm more worried about a year (or 18 months?) from now; again some of Benjamin's 
comments sounded like there is a desire in some quarters to keep the 
early-development setup indefinitely.

> If you have a hundred API entry points (think Unix kernel of old;
> several hundred now, I'm sure, plus device driver APIs, and later
> virtual filesystem APIs), the subset of apps you try not to break can
> be large, but it won't be tested fully except over long pre-release
> cycles. So not "all at once".

Right.

Note that in my mind there is a difference between "API change breaks part of an 
application's functionality" and "API change makes application not compile". 
The latter is a lot worse, since it prevents work by others on the app.  So it 
makes a certain amount of sense to have a small time investment by one person 
(the one making the API change) to save time for N others.  If the time 
investment is not small, then the one person should contact the relevant app 
owners.  We do all this like that now anyway.

> I agree we may end up with another XUL app hosted in the new
> repository, but I do not agree that we must host a second XUL app.

I should reiterate that I think where things are hosted is orthogonal to the 
tree rules we enforce.  Especially if there is checkout/build glue to pull and 
build several apps on top of the same (shared!) XULRunner, for those who want to 
make sure their checkins don't break things before hitting tinderbox with them.  ;)

In any case, it does sound like we basically agree on what should happen, both 
short-term and long-term.  Thank you for alleviating my concerns!

-Boris

Benjamin Smedberg wrote:
> My proposal was mainly focused on the fact that we now have the opportunity
> to break binary compatibility with XPCOM, and have several very good reasons
> to do so:
....
> #1 could be accomplished without significant code-level changes

I'm very happy doing anything like that.  I have no problem with telling people 
they need to recompile their apps for Mozilla2.  I'm not as happy telling them 
they have to rewrite all their code.

> #2 and #3 could possibly be achieved through automatic code rewriting
> (though we don't know yet how well that will work), and can happen
> incrementally.

Could be happy with this too, especially if we have good documentation and 
availability for the code-rewriting stuff so that someone porting from mozilla1 
to mozilla2 can take advantage of it.  That is, we document what rewrites we did 
and put up something that can apply those rewrites to third-party code.

> I'm not saying we should "rewrite XPCOM" from the ground up. Rather that we
> can make changes to the existing framework that are radical, without
> requiring everyone to rewrite everything.

As long as we have that "without requiring everyone to rewrite everything" goal, 
I'm on board.  ;)

> And that we should seriously
> consider making the "JS2 API" the thing we freeze in the future, and should
> not re-freeze XPCOM interfaces.

Also makes sense.

-Boris

On Apr 2, 12:51 pm, Axel Hecht <a...@pike.org> wrote:
> While I do follow the argument that the Mozilla2 team should not migrate
> every app and interface out there, I do think that it's the
> responsibility of that team to pave the road for migration, and to drive
> testing enviroments for particular features that need to be kept alive
> outside of what Firefox currently does. Not sure if there's a whole lot
> more than editing here, the ecosystem would know.

The ecosystem has no single voice, even if it has a group mind. We
have to work through the details using newsgroups such as m.d.platform
along with wiki.mozilla.org.

I do not propose, and have never proposed, that we swing the ax wildly
at APIs for Mozilla 2. I suspect that we will end up with XPCOM still
around, and I've cautioned against planning to remove it altogether.
We should be careful not to remove any working API without a lot of
thought and discussion. But remove APIs we will; I think many of us
have candidates for removal, as well as for upgrading/redesigning to a
supportable, public API.

We will use a public "request for comments" protocol where any API
removal or incompatible change is proposed before disposed.  Please
read and (if you have access and something to add) edit
http://wiki.mozilla.org/Mozilla_2:Obsolete_APIs to help develop this
"RFC" idea.

/be

brendan@mozilla.org wrote on 02. Apr 2007

[Brendan, I also sent you a (slightly different) mail about this.

>>>> Just to clarify here, did you say that you would like to leave
>>>> Thunderbird with build problems that are impossible to fix?
>> 
>>> No, but I think it's possible that we will end up in that situation
>>> unless a much larger community that can hack mailnews appears.
>> 
>> So MoCo is essentially abandoning its second product (Thunderbird)
>> in favor of Firefox?
> 
> Yikes. You just twisted what Benjamin actually wrote into something
> completely different. Benjamin wrote "it's possible that we will end
> up with [Thunderbird build support costing Benjamin and the few
> others who work on the build system way too much]" and you take that
> as "MoCo is abandoning Thunderbird."
> 
> Do you not see the difference? I'm having a hard time believing this
> was an innocent misreading.

Please try to see it from my side. You are announcing a majo
reorganization/rewrite/whatever of the mozilla backend platform and ar
also announcing, that this will be done only on Firefox and XULRunner

You are also announcing that you are changing the tree rules to 
significant extent

Does it really surprise you, that some people outside of the MoC
inner circle seem to see bad implications coming from this. Rober
voiced some concerns in the discussion and I know from discussion
with Calendar developers, that I'm not the only one having doubts

The comments from the Calendar devs that I spoke with generally wen
into the direction of "MoCo did not, does not and never will car
about us, it cares and will always care only about Firefox"

I know that this is again a feelings-based statement, but I think yo
should be aware of the feelings of the community outside of the Firefo
ecosystem. What you make of this, is of course your choice

Please also consider, that in blog posts lik
http://www.allpeers.com/blog/2007/03/22/the-future-of-applications/ o
http://blog.mozbox.org/post/2007/03/21/ApolloDecolle (translation a
http://www.allpeers.com/blog/2007/04/01/apollo-takes-off/) other peopl
voiced their concerns, which, although not identical with mine, seem t
go in a similar direction IMO

> Firefox >> Thunderbird. This isn't a "MoCo" thing, it's a fact that's
> obvious based on active user counts, buzz, effect on the competition,
> effect on the web, etc. etc.
> 
> This does *not* mean that only Firefox matters, or that other XUL apps
> must be broken all the time. But without a Mozilla 2 that focuses on
> APIs and embedding, where "focuses" means "does not have to keep all
> current API clients hosted in cvs.m.o working at all times, or even
> for a long stretch up front", then everyone will face rising costs,
> conflicts over bad APIs, and build system divergence.

I fully understand. But please also understand, that from my point o
view, there is a big difference when you or Ben are saying, "We wil
not fix breakages in community projects like Calendar or Seamonkey
to "We will not fix breakages in our 2nd product Thunderbird"

> Here's my own controversial opinion. Please don't lay it at the feet
> of "MoCo" and act as if you are discerning some Evil Plot against
> other XUL apps:
> 
> The best thing that could happen for Thunderbird would be to grow the
> larger community that Benjamin believes will be needed to keep its
> build system converged with the base XULRunner/Firefox one, and do
> other things such as calendar integration. That effort should be done
> in as focused and open-source a way as possible, which is not the case
> so long as "MoCo" is paying for almost all active Thunderbird dev/
> build/QA. Without such a community, Thunderbird will suffer rising
> costs to everyone (not just to "MoCo") relative to benefits to its
> users.

I totally agree. The Thunderbird development community outside of MoC
is very small and there hasn't been a significant effort to change that

So why I absolutely support your assertion that the Thunderbir
community must grow beyond MoCo. I think that without an up-fron
effort from MoCo or its paid developers to grow the mail-related
community, this will be very hard to do.

You actually did that with Firefox in a very successful way, by
creating spreadfirefox.com, hiring people to improve the ease of
extension development, etc.

In addition Firefox people have shown significant effort to communicate
with the community in a very open and direct way. The huge number of
blogs dedicated to the various parts of Firefox development from MoCo
exployees is a good indicator for that.

I don't see this from mailnews people at all. I know that mscott was
posting in the mozillazine forums (I don't know if that's still the
case) and he and bienvenu are both on IRC I believe, but that's
basically it.

I don't know the reason of this. Are mscott and bienvenu not interested
in communicationg with the community (I can't imagine that)? Is their
workload so high? Are they required to serve other master (e.g.
commercial customers of MoCo with customized Thunderbird builds) as 
well?

I can only say, judging from my experience in the Calendar camp and in
dealing with folks from Seamonkey, that active communication is *the*
major key in growing and keeping in touch with the community and that
both Calendar and Seamonkey seem to do a pretty good job with it
(judging from the feedback we're getting).

> You might argue that "MoCo" should throw *more* money at Thunderbird.

As I said above, I think that to actually grow the mail-related
community it would need at least a temporary up-front investment. You
could do that by either employing more people or by freeing mscott
and bienvenu from others duties, so they can more actively approach
the community.

> That would inevitably mean less focus and fewer people working on
> Firefox and the core Gecko/XULRunner code.

Not necessarily, as I mentioned above.

> Yet it would also make Thunderbird even less of an open source
> project with significant patch inflow from various committers,

This can be a possible outcome, if it's done in the wrong fashion. If
you do it right, the opposite can (and will) happen.

> Don't take this to mean that money is the issue. As a board member of
> Mozilla Foundation, I'm happy to spend on Thunderbird *if* there's a
> plan and signs of a community that will develop it to the degree that
> it needs to be developed, and in different-in-kind ways, all while
> keeping its build system from diverging. Money alone won't provide
> these things, and money spent badly would actually harm Thunderbird.

I fully agree. How can this be solved? Who can/should develop a plan
to further validate MoFo's money spending regarding Thunderbird? It
seems to me, that you are frustrated with the current state of
Thunderbird. What can be done to change that? What can you do? What
can I do? What can others do?

What about mscott and bienvenu? Can they chime in here and post their
views on this topic?

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

brendan@mozilla.org wrote:
> On Apr 2, 12:51 pm, Axel Hecht <a...@pike.org> wrote:
>> While I do follow the argument that the Mozilla2 team should not migrate
>> every app and interface out there, I do think that it's the
>> responsibility of that team to pave the road for migration, and to drive
>> testing enviroments for particular features that need to be kept alive
>> outside of what Firefox currently does. Not sure if there's a whole lot
>> more than editing here, the ecosystem would know.
> 
> The ecosystem has no single voice, even if it has a group mind. We
> have to work through the details using newsgroups such as m.d.platform
> along with wiki.mozilla.org.
> 
> I do not propose, and have never proposed, that we swing the ax wildly
> at APIs for Mozilla 2. I suspect that we will end up with XPCOM still
> around, and I've cautioned against planning to remove it altogether.
> We should be careful not to remove any working API without a lot of
> thought and discussion. But remove APIs we will; I think many of us
> have candidates for removal, as well as for upgrading/redesigning to a
> supportable, public API.
> 
> We will use a public "request for comments" protocol where any API
> removal or incompatible change is proposed before disposed.  Please
> read and (if you have access and something to add) edit
> http://wiki.mozilla.org/Mozilla_2:Obsolete_APIs to help develop this
> "RFC" idea.

That looks good from an API point of view.

Could we pair that with some functional testing? Maybe we could convince 
glazou to contribute a mini-composer xulrunner app which can then go 
through some eggplant tests or something. I guess one could find 
caret-bustages and the like in an automated way.

Axel

Simon Paquet aber hob zu reden an und schrieb:
> So why I absolutely support your assertion that the Thunderbird
> community must grow beyond MoCo. I think that without an up-front
> effort from MoCo or its paid developers to grow the mail-related
> community, this will be very hard to do.
> 
> You actually did that with Firefox in a very successful way, by
> creating spreadfirefox.com, hiring people to improve the ease of
> extension development, etc.

Actually, I think you can't quite compare both here.

Browsers are still a relatively new technique and there is only
relatively few (serious) competition. Furthermore, browsers are based on
*visuality*, on eye candy and (even more nowadays) interaction.

Mail (or news) clients, otoh, are rather dull, I have to confess. You
basically "just" move texts around, order them, search them. While a
browser can very well be a kind of toy, a mail client is tool of work.
It's prime directive ;-) is efficiency, getting folks to get done with
their mail as fast and easily as possible. Furthermore, the competition
is hard: mail is out there for almost three decades, lots and lots of
programs for almost every possible thing you can do with it are already
available! MailNews as a part of SM has the advantage of being part of a
suite of everything you basically need for the net, but a standalone
mailer like TB needs *reasons*, *justifications* even more to get used -
like its Bayes filter, like it's cross platform, etc.

> In addition Firefox people have shown significant effort to communicate
> with the community in a very open and direct way. The huge number of
> blogs dedicated to the various parts of Firefox development from MoCo
> exployees is a good indicator for that.
> 
> I don't see this from mailnews people at all. I know that mscott was
> posting in the mozillazine forums (I don't know if that's still the
> case) and he and bienvenu are both on IRC I believe, but that's
> basically it.
> 
> I don't know the reason of this. Are mscott and bienvenu not interested
> in communicationg with the community (I can't imagine that)? Is their
> workload so high? Are they required to serve other master (e.g.
> commercial customers of MoCo with customized Thunderbird builds) as 
> well?

Mail is a shy business. ;-)
Like I said above, it's kind of easy to make a hubbub about yet another
animated graphics format. People come and see and spread the news, even
and especially when they're not actual developers, but artists etc. Now
imagine something like that for a mailer - even the most nifty spam
catching neural net will not be a fun toy but just a tool to help you to
not get annoyed. And not getting annoyed isn't actually equal to having
fun...

>> Yet it would also make Thunderbird even less of an open source
>> project with significant patch inflow from various committers,
> 
> This can be a possible outcome, if it's done in the wrong fashion. If
> you do it right, the opposite can (and will) happen.

Apart from the above, MailNews and Thunderbird do have a longstanding
burden in form of a 90ies archaic basic library imposing some workflow
in the fronend which is not very easy to hack for extension authors. The
learning curve for useful ;-) addons is quite high (which also explains
why there are still unported features when compared to Netscape
Navigator 4.x!)...

> I fully agree. How can this be solved? Who can/should develop a plan
> to further validate MoFo's money spending regarding Thunderbird? It
> seems to me, that you are frustrated with the current state of
> Thunderbird. What can be done to change that? What can you do? What
> can I do? What can others do?
> 
> What about mscott and bienvenu? Can they chime in here and post their
> views on this topic?


Karsten
-- 
Feel free to correct my English. :)

Simon Paquet wrote:
> brendan@mozilla.org wrote on 02. Apr 2007:
> 
> [Brendan, I also sent you a (slightly different) mail about this.]

I'll reply here.

> Please try to see it from my side. You are announcing a major
> reorganization/rewrite/whatever of the mozilla backend platform and are
> also announcing, that this will be done only on Firefox and XULRunner.

I think you are misstating the Mozilla 2 plan. We do not propose to 
rewrite all front ends for a new back end. We don't propose to change 
every, or even necessarily most, APIs (but we may change all C++-only 
APIs -- we need that freedom).

Other than Firefox, which has special status along with XULRunner, 
front-end porting to Mozilla 2 is a job for each front-end project to 
work on. I do not have Camino commit access, and I don't want it. So 
there never was and never will be a free lunch here.

Hosting Camino (let's use it instead of Thunderbird) in the Mozilla 2 
repository is not the issue, either. Hosting != tinderbox build coverage 
!= API design feedback != API porting division of labor.

I keep repeating that we must focus on the Mozilla 2 goals (JS2 via 
Tamarin+SpiderMonkey, automated refactoring and deCOMtamination, 
embedding, layout and graphics competitiveness) to the exclusion of API 
compatibility where we justify breaking it.

I also keep saying that we will fail if we require ourselves to keep all 
cvs.m.o-hosted apps working all the time during the bulk of the back end 
rework for Mozilla 2.

This point is important. I don't think you've responded to it head-on. 
Feelings and fears or accusations against "MoCo" don't make sense until 
you confront the insuperable practical problem of doing Mozilla 2 while 
keeping all the hosted XUL apps, or even more than two of them, working.

> You are also announcing that you are changing the tree rules to a
> significant extent.

Yes, but this is for the new tree, based on the premise I keep repeating 
-- we are not deciding *next year's* tree rules, but we are strongly 
suggesting that new VCSes and better embedding APIs make way for other 
hosting arrangements, no matter the tree rules.

So we are trying to get started without having to solve the tree rule 
problem in 2008, or even 2009. You seem to want us to keep the current 
tree rules (Firefox, SeaMonkey, Thunderbird) for the new Mozilla 2 repo 
from day 1. I repeat again that's suicide.

> Does it really surprise you, that some people outside of the MoCo
> inner circle

What MoCo inner circle?

The Mozilla 2 work has been doing via blogs and wiki.mozilla.org. 
Nothing is being done "in secret".

I think you are out of line using such inflammatory language. But apart 
from *my* feelings, that language is demonstrably fact-free.

> seem to see bad implications coming from this. Robert
> voiced some concerns in the discussion and I know from discussions
> with Calendar developers, that I'm not the only one having doubts.

Robert seems to be doing fine in his posts, and you have a reply from 
Karsten that doubts some of your assertions. Let's stop trying to rally 
others and name-drop as if we are in a political campaign, please. This 
is m.d.platform, and I'm very concerned about practicalities of Mozilla 
2 development concurrent with 1.9. That's the problem to solve.

Turning this into a "I doubt MoCo 'cares' for other XUL apps than 
Firefox" is both:

1. irresponsible -- sayrer's right, we have to favor Firefox, "we" being 
the whole community, but especially MoCo (as distinct from MoFo); and

2. categorically confused -- emotional when the topic here is technical: 
how to do Mozilla 2 so that all XUL apps have a better future, without 
serializing with 1.9 or taking on impossible workload in keeping to the 
current tree rules every day we develop Mozilla 2 in the new repo.

> The comments from the Calendar devs that I spoke with generally went
> into the direction of "MoCo did not, does not and never will care
> about us, it cares and will always care only about Firefox".

Stop looking for "care" and consider the point sayrer made.

Free lunches are a bad idea in general. As I wrote, with a good plan for 
Thunderbird, I hope and expect that Mozilla Foundation (again I'm on the 
board) will support a separately focused effort for Thunderbird that is 
independent of the Firefox and XULRunner effort except to the extent 
that the common platform needs shared work -- which is best done via 
Mozilla 2's rearchitecture of the code and APIs.

> I know that this is again a feelings-based statement, but I think you
> should be aware of the feelings of the community outside of the Firefox
> ecosystem. What you make of this, is of course your choice.

Feelings are inarguable, so all I can do is try to appeal to your 
reason, your technical judgment.

> Please also consider, that in blog posts like
> http://www.allpeers.com/blog/2007/03/22/the-future-of-applications/ or
> http://blog.mozbox.org/post/2007/03/21/ApolloDecolle (translation at
> http://www.allpeers.com/blog/2007/04/01/apollo-takes-off/) other people
> voiced their concerns, which, although not identical with mine, seem to
> go in a similar direction IMO.

You are mixing up VCS hosting of XUL apps currently hosted on cvs.m.o 
with tree rules, and with XUL as a platform (which does not necessarily 
depend on either hosting or tree rules). Again this seems like vague 
connect-the-dots political campaigning.

All I can say is that XUL as a platform cannot be the focus ahead of 
Firefox, or we are doomed.

And I'll add (again) that the best hope for XUL as a platform, apart 
from uplifting pieces of XUL along with other stuff (such as offline app 
support) into the web standards, is Mozilla 2.

>> Firefox >> Thunderbird. This isn't a "MoCo" thing, it's a fact that's
>> obvious based on active user counts, buzz, effect on the competition,
>> effect on the web, etc. etc.
>>
>> This does *not* mean that only Firefox matters, or that other XUL apps
>> must be broken all the time. But without a Mozilla 2 that focuses on
>> APIs and embedding, where "focuses" means "does not have to keep all
>> current API clients hosted in cvs.m.o working at all times, or even
>> for a long stretch up front", then everyone will face rising costs,
>> conflicts over bad APIs, and build system divergence.
> 
> I fully understand. But please also understand, that from my point of
> view, there is a big difference when you or Ben are saying, "We will
> not fix breakages in community projects like Calendar or Seamonkey"
> to "We will not fix breakages in our 2nd product Thunderbird".

Not in the Mozilla 2 repo we set up this year. Not now.

If Thunderbird ports to XULRunner and gets going on Mozilla 2 in due 
course, great. We can revisit the tree rules then, as bz and I already 
agreed. We do not need to co-host, however -- that's a non-requirement.

> So why I absolutely support your assertion that the Thunderbird
> community must grow beyond MoCo. I think that without an up-front
> effort from MoCo or its paid developers to grow the mail-related
> community, this will be very hard to do.

Then we disagree (we've been over this already). MoCo won't be spending 
more on closed-source-like dev/build/qa than it already has. The Mozilla 
Foundation is actively investigating a better plan.

> You actually did that with Firefox in a very successful way, by
> creating spreadfirefox.com, hiring people to improve the ease of
> extension development, etc.

Firefox was already a rocket unlike any other XUL app well before MoFo 
(there was no MoCo then) had more than ten full time employees. Please 
don't revise history.

> In addition Firefox people have shown significant effort to communicate
> with the community in a very open and direct way. The huge number of
> blogs dedicated to the various parts of Firefox development from MoCo
> exployees is a good indicator for that.

Yes, Firefox >> Thunderbird. I don't know how else to put this. If you 
are arguing for subsidized blogs, they won't help; that's not the good 
plan Thunderbird needs.

> I don't see this from mailnews people at all. I know that mscott was
> posting in the mozillazine forums (I don't know if that's still the
> case) and he and bienvenu are both on IRC I believe, but that's
> basically it.

They are the only paid Thunderbird developers. Adding more inside MoCo 
is a terrible idea and I've said why several times.

> I don't know the reason of this. Are mscott and bienvenu not interested
> in communicationg with the community (I can't imagine that)? Is their
> workload so high?

Why don't you ask them?

> Are they required to serve other master (e.g.
> commercial customers of MoCo with customized Thunderbird builds) as well?

No, there's no paying commercial customer pulling Thunderbird developer 
focus. We've passed up relatively-small-money-at-high-cost opportunities 
here.

> I can only say, judging from my experience in the Calendar camp and in
> dealing with folks from Seamonkey, that active communication is *the*
> major key in growing and keeping in touch with the community and that
> both Calendar and Seamonkey seem to do a pretty good job with it
> (judging from the feedback we're getting).

I agree, of course.

>> You might argue that "MoCo" should throw *more* money at Thunderbird.
> 
> As I said above, I think that to actually grow the mail-related
> community it would need at least a temporary up-front investment.

Not from MoCo, not at the expense of Firefox and Mozilla 2.

Management 101: an organization does at most one thing well. The Mozilla 
community does many things well, some better than others. And some 
things, say Firefox, are inherently stronger products than others. All 
of this says any Thunderbird subsidy ("up-front investment") will be 
separate from MoCo, and as a MF board member I will insist on this.

> You
> could do that by either employing more people or by freeing mscott
> and bienvenu from others duties, so they can more actively approach
> the community.

They're not constrained from community involvement now. It's wrong to 
insinuate otherwise.

>> That would inevitably mean less focus and fewer people working on
>> Firefox and the core Gecko/XULRunner code.
> 
> Not necessarily, as I mentioned above.

No, necessarily. No free lunch. You can't add people to make things 
happen without consequence. See Fred Brooks.

Money is not the issue. Hiring is one issue. Management bandwidth is 
another. Build infrastructure is yet another. Organization focus is yet 
another, and it's a vague term, but obvious to anyone who has worked at 
a startup that grew into a big company. I could write about it at length 
and define it concretely, but I'm out of time here.

>> Yet it would also make Thunderbird even less of an open source
>> project with significant patch inflow from various committers,
> 
> This can be a possible outcome, if it's done in the wrong fashion. If
> you do it right, the opposite can (and will) happen.

This is the challenge for the Mozilla Foundation, I agree.

What this has to do with the initial import into hg for Mozilla 2, I 
have no idea at this point. I'll leave it to others to continue the new 
thread you started with this message (which google groups seems not to 
have linked properly, for some reason).

>> Don't take this to mean that money is the issue. As a board member of
>> Mozilla Foundation, I'm happy to spend on Thunderbird *if* there's a
>> plan and signs of a community that will develop it to the degree that
>> it needs to be developed, and in different-in-kind ways, all while
>> keeping its build system from diverging. Money alone won't provide
>> these things, and money spent badly would actually harm Thunderbird.
> 
> I fully agree. How can this be solved? Who can/should develop a plan
> to further validate MoFo's money spending regarding Thunderbird? It
> seems to me, that you are frustrated with the current state of
> Thunderbird. What can be done to change that? What can you do?

I'm focusing on Mozilla 2. That's necessary and overriding. Thunderbird 
will have to fly free. If it does not reach a promised land, even with a 
good plan and some investment, I will be sad. But I will not jeopardize 
Firefox and the platform, which depend on Mozilla 2, by spending more 
time on it than my MF board duties require.

So again, apart from my board duties you won't hear from me on this 
thread. And I'm not going to speak for the Mozilla Foundation board, or 
preempt them in any way. All the above is my opinion, which I've shared 
before. I've given my reasoning. I hope it's both sound and valid, and 
that it can overcome raw feelings and help others, so that we can all 
improve the situation.

/be

Brendan Eich schrieb:
> I'm focusing on Mozilla 2. That's necessary and overriding. Thunderbird 
> will have to fly free. If it does not reach a promised land, even with a 
> good plan and some investment, I will be sad. But I will not jeopardize 
> Firefox and the platform, which depend on Mozilla 2, by spending more 
> time on it than my MF board duties require.

I think we actually all stand united in wanting all of our current 
Mozilla apps and even more to survive into being vibrant 
Mozilla2-XULRunner-based apps in some, maybe still somewhat distant, future.

I think what Simon fears, just like still do to a certain extent, is 
that focusing on the XULRunner+Firefox core may lead to making life 
harder for other non-browser-only apps, instead of making XULRunner a 
broader platform that can easily be used by a growing number of great 
applications.

I hope though, that we all can, as a great community, create some kind 
of infrastructure (including very much the hosting and build system) for 
Mozilla2 that can make XULRunner a really good and well-tested base for 
a steadily growing set of really great software.
This includes the mozilla.com/org-hosted apps like Thunderbird, 
SeaMonkey, Sunbird, Minimo, and Camino but goes well beyond that.

We just need to make sure that we are not narrowing our vision to 
Firefox alone, but rather extend it to satisfying as much of that 
community as reasonable.

Robert Kaiser

Robert Kaiser wrote:
> Brendan Eich schrieb:
>> I'm focusing on Mozilla 2. That's necessary and overriding. 
>> Thunderbird will have to fly free. If it does not reach a promised 
>> land, even with a good plan and some investment, I will be sad. But I 
>> will not jeopardize Firefox and the platform, which depend on Mozilla 
>> 2, by spending more time on it than my MF board duties require.
> 
> I think what Simon fears, just like still do to a certain extent, is 
> that focusing on the XULRunner+Firefox core may lead to making life 
> harder for other non-browser-only apps, instead of making XULRunner a 
> broader platform that can easily be used by a growing number of great 
> applications.

You've described a fear and a dichotomy, but there is no rationale. See 
below.

> 
> We just need to make sure that we are not narrowing our vision to 
> Firefox alone, but rather extend it to satisfying as much of that 
> community as reasonable.

Let's refocus this discussion. I think we can agree that the current 
Mozilla platform, like all successful software, has some serious 
architectural problems. We need to solve some of them to maintain our 
rate of growth. This task requires revisiting areas of the code that 
essentially every Mozilla application relies on.

If you have serious architectural problems, it's a good idea to assign a 
team to tackle them. Of course, the problem with those teams is that 
they're assigned an architectural problem--they might become 
architecture astronauts[1]. We need to give them a customer. Firefox is 
a sensible one, since basically all Mozilla applications share code with 
it, and it is the most popular by orders of magnitude.

Should the Mozilla 2 platform team have a Usenet requirement?  Should it 
have an OS X .nib file requirement? Should it have an iCalendar 
requirement? A Windows Mobile requirement? A Television requirement? A 
social networking requirement?

The answer to all of these questions is: no. It is possible the Mozilla 
2 team will initially turn up with something not quite right for other 
apps. They might have to make some adjustments. But that is far better 
than turning up with something that claims to solve everyone's problem 
but actually does nothing.

Don't give people the impossible task of creating a "broad platform".

- Rob

[1] http://www.joelonsoftware.com/articles/fog0000000018.html

Robert Sayre aber hob zu reden an und schrieb:
> If you have serious architectural problems, it's a good idea to
> assign a team to tackle them. Of course, the problem with those teams
> is that they're assigned an architectural problem--they might become
> architecture astronauts[1]. We need to give them a customer. Firefox
> is a sensible one, since basically all Mozilla applications share
> code with it, and it is the most popular by orders of magnitude.

Nicely said, but the direction implied is not that true.
If you would design an architecture and use Firefox as a "reminder" that
you don't do it for the thing itself but for applications to use it - fine!
But many folks have seen, especially with the aviary XPFE -> toolkit
move, that eg. the primary goal was "make toolkit do what Firefox needs
right now" and not "make toolkit do something sensible that Firefox can
use". "We're only a browser" is no useful way to design a *platform's* APIs.
This is the experience where the paranoia here comes from.

> The answer to all of these questions is: no. It is possible the
> Mozilla 2 team will initially turn up with something not quite right
> for other apps. They might have to make some adjustments.

But it's doubtful that they do, experience shows.
That's the whole point.

> But that is far better than turning up with something that claims to
> solve everyone's problem but actually does nothing.

Well, "we are browser, resitance is futile" is no platform.

> Don't give people the impossible task of creating a "broad platform".

But what's the point of having a narrowly browser-focused base for
non-browser projects? A browser is not a platform (in the sense that
"Mozilla platform" is used still, usually).

Look, if Firefox developers would just remind themselves that they're
part of a community that does *not* consist of just a browser, and could
be "trusted" not to make deliberate exclusions on the base "we browser
will never need that", everything's fine...

It's reasonable, no doubt, to concentrate first on getting the thing
started including _some_ real-world testing, while leaving out other
parts. But in choosing such a path, you have to be very careful that you
define the platform as such solely upon the immediate needs of the
testing subject.


Karsten
-- 
Feel free to correct my English. :)

Robert Sayre schrieb:
> Should the Mozilla 2 platform team have a Usenet requirement?  Should it 
> have an OS X .nib file requirement? Should it have an iCalendar 
> requirement? A Windows Mobile requirement? A Television requirement? A 
> social networking requirement?
> 
> The answer to all of these questions is: no.

Right. Even a tabbrowser widget does not belong there (and before anyone 
screams, I know that mconnor does agree here - it's currently misplaced 
in toolkit and should go Firefox-specific, hopefully even in the FF3 
timeframe).
What belongs there are APIs that are well-useable by not-only-browser or 
completely non-browser apps. For example, I believe that IPC (e.g. 
handling of named and anonymous pipes from JS code) belong there - even 
if Firefox might not actively use that (in the first place).
Good support for image format extensions (including those for encoding) 
belongs there. Task tray icon support belongs there, even if Firefox 
doesn't use it. Hooks for plugging in a splash screen to be shown at 
startup belong there (not the splash itself, of course, and in a way 
that apps not using it don't get slowed down by that code) - again, even 
if Firefox doesn't use it. All those functions are currently wanted by 
other Mozilla-based apps, including platform consumers outside 
mozilla.org itself. And the list can probably be continued.

> Don't give people the impossible task of creating a "broad platform".

With "broad" I didn't mean to imply it has to have all kinds of 
end-user-oriented features itself. That would be wrong for sure.
I meant it should be broad enough API-wise so that it can widely be used 
by all kinds of (Internet-related) apps. It should be easy for such an 
apps to implement support for usenet, .nib files, iCalendar, Windows 
Mobile support, TV, social network, all on top of our platform and - as 
far as reasonably possible - without too ugly hacks.

In some cases, discussion will arise (as they already do) if something 
belongs in the platform (XULRunner) or the app itself. Those discussions 
are good, and I think the criteria in most cases should be how usable 
the feature is to the app community, and not to one single app (like, 
say Firefox).

No doubt, Firefox is the premier app of the Mozilla community, and its 
success is just great. We are the Mozilla platform though, not the 
Firefox platform, we are interested in being and supporting more than 
just that leading application with XULRunner, AFAIK.
All I'm saying is that we should try to keep that in mind with Mozilla2 
and make it easy enough for others to use that platform. That includes 
testing and building, of course - in a reasonable timeframe (that 
doesn't have to be from the beginning itself, we're all busy enough to 
make our Gecko-1.9-based products into something usable).

Robert Kaiser

Robert Kaiser wrote:

> No doubt, Firefox is the premier app of the Mozilla community, and its
> success is just great. We are the Mozilla platform though, not the
> Firefox platform, we are interested in being and supporting more than
> just that leading application with XULRunner, AFAIK.
> All I'm saying is that we should try to keep that in mind with Mozilla2
> and make it easy enough for others to use that platform. That includes
> testing and building, of course - in a reasonable timeframe (that
> doesn't have to be from the beginning itself, we're all busy enough to
> make our Gecko-1.9-based products into something usable).

I think we need to be careful here. The primary consumer of our "platform"
is web developers. The extent to which we consider the needs of XPCOM+XUL
applications depends on their alignment with the goal of improving the web
and promoting open standards. Mozilla2 is focusing on improving the layout
(box model and templates), interactive support (native/UI theming), and
extensibility (XBL and overlays) of the web (HTML). Plus of course the
vastly improved language support that will be JS2. Providing a stable and
supported XUL language or XPCOM APIs is a secondary goal or even a non-goal.

The browser-y apps like SeaMonkey/Songbird/Thunderbird are a grey area. They
are much less influential on the web than Firefox (in economic terms, they
have much less leverage). Their needs are secondary to the primary goals of
the platform. This is not to say that the platform team should not consider
their needs or will suddenly stop working with those communities. But the
burden of integration should be placed primarily with those application
communities, not with the core mozilla community.

I think Songbird is a refreshingly good example of an external project
integrating well with the mozilla community. We have active communication
channels, and when Songbird needs a change in the platform, they discuss the
design and provide patches. In return, when platform devs make changes that
might affect them, we try to let them know and provide design input if
appropriate. Overall, working with the Songbird team has been positive for
the platform (and I think for them as well). Although they are still
releasing products off the branch codebase, they are tracking the trunk for
regression testing.

I think SeaMonkey and Thunderbird need to be in the same status as Songbird:
there should no longer be a special entitlement or tinderbox tree rules that
require mozilla developers to spend time on those products if it does not
make sense to do so. It's not that we're dropping them on the floor to rot
and die. Just gently pushing them to develop self-sufficient communities
that have a good working relationship with the core mozilla community.

There's lots of work to do, no doubt. luser and I are going to be working on
improvements to the build system (especially the configure scripts) which
will make building apps on top of our platform less incestuous.

That's what "there's no free lunch" means to me, at least.

--BDS

Benjamin Smedberg wrote:
> Robert Kaiser wrote:
> 
>> No doubt, Firefox is the premier app of the Mozilla community, and its
>> success is just great. We are the Mozilla platform though, not the
>> Firefox platform, we are interested in being and supporting more than
>> just that leading application with XULRunner, AFAIK.
>> All I'm saying is that we should try to keep that in mind with Mozilla2
>> and make it easy enough for others to use that platform. That includes
>> testing and building, of course - in a reasonable timeframe (that
>> doesn't have to be from the beginning itself, we're all busy enough to
>> make our Gecko-1.9-based products into something usable).
> 
> I think we need to be careful here. The primary consumer of our "platform"
> is web developers. The extent to which we consider the needs of XPCOM+XUL
> applications depends on their alignment with the goal of improving the web
> and promoting open standards. Mozilla2 is focusing on improving the layout
> (box model and templates), interactive support (native/UI theming), and
> extensibility (XBL and overlays) of the web (HTML). Plus of course the
> vastly improved language support that will be JS2. Providing a stable and
> supported XUL language or XPCOM APIs is a secondary goal or even a non-goal.

Benjamin, just redefining what platform is is bad. I'm not going to 
follow you, and I do strongly hope you drop it. What you're essentially 
doing is stealing language from the community, which means, you're 
taking away the means with which everything that is not just Firefox can 
contribute to Mozilla 2. Statements like this really build up a barrier 
for absolutely no value.

Axel

> The browser-y apps like SeaMonkey/Songbird/Thunderbird are a grey area. They
> are much less influential on the web than Firefox (in economic terms, they
> have much less leverage). Their needs are secondary to the primary goals of
> the platform. This is not to say that the platform team should not consider
> their needs or will suddenly stop working with those communities. But the
> burden of integration should be placed primarily with those application
> communities, not with the core mozilla community.
> 
> I think Songbird is a refreshingly good example of an external project
> integrating well with the mozilla community. We have active communication
> channels, and when Songbird needs a change in the platform, they discuss the
> design and provide patches. In return, when platform devs make changes that
> might affect them, we try to let them know and provide design input if
> appropriate. Overall, working with the Songbird team has been positive for
> the platform (and I think for them as well). Although they are still
> releasing products off the branch codebase, they are tracking the trunk for
> regression testing.
> 
> I think SeaMonkey and Thunderbird need to be in the same status as Songbird:
> there should no longer be a special entitlement or tinderbox tree rules that
> require mozilla developers to spend time on those products if it does not
> make sense to do so. It's not that we're dropping them on the floor to rot
> and die. Just gently pushing them to develop self-sufficient communities
> that have a good working relationship with the core mozilla community.
> 
> There's lots of work to do, no doubt. luser and I are going to be working on
> improvements to the build system (especially the configure scripts) which
> will make building apps on top of our platform less incestuous.
> 
> That's what "there's no free lunch" means to me, at least.
> 
> --BDS

Benjamin Smedberg wrote:
> I think we need to be careful here. The primary consumer of our "platform"
> is web developers. The extent to which we consider the needs of XPCOM+XUL
> applications depends on their alignment with the goal of improving the web
> and promoting open standards.

Yes, but the alignment might be non-obvious.  For example, we consider the needs 
of Firefox extensions, because those make Firefox more popular, etc.

 > Providing a stable and
> supported XUL language or XPCOM APIs is a secondary goal or even a non-goal.

I think as a blanket statement that's a sever mistake.  Providing improved 
security for XUL apps and extensions _is_ a goal, for example.

That said, I'm curious.  When and where did the goals discussion for Mozilla 2 
happen?  Did I miss it somehow?

> But the burden of integration should be placed primarily with those application
> communities, not with the core mozilla community.

What is your definition of "core mozilla community" here?

 From where I sit, there is significant overlap in terms of people between, say, 
the "Seamonkey community" and what I would consider the "core mozilla 
community".  But maybe you're using different definitions?

And maybe I'm having a knee-jerk reaction to narrow definitions of "core" and 
"external" from back in 2000 or so....  But maybe not.

I'd very much like a response on this point; it bothers me a lot.

> I think Songbird is a refreshingly good example of an external project
> integrating well with the mozilla community.

That's true.

> I think SeaMonkey and Thunderbird need to be in the same status as Songbird:
> there should no longer be a special entitlement or tinderbox tree rules that
> require mozilla developers to spend time on those products if it does not
> make sense to do so.

How are we determining when it makes sense to do so?

> It's not that we're dropping them on the floor to rot
> and die. Just gently pushing them to develop self-sufficient communities
> that have a good working relationship with the core mozilla community.

I guess my point is that given the overlaps in people between the various 
communities, it might be a _better_ time investment for core changes to just 
include the non-Firefox apps in some cases.  I'm not talking about complicated 
things (which already get split up into multiple parts handled by the app folks 
in addition to the core patch).  I'm talking about simple API changes, where the 
time investment on the part of the patch author to do a few more cases is 
usually small, whereas the time investment on the part of others to figure out 
how to make the change at all and then make it is large.  At that point, we're 
wasting the time it takes the N other people to figure out what the change was.

Here's a more concrete example.  If it turns out that biesi and I are spending 
more (or possibly even comparable) time integrating Seamonkey than it would take 
for the initial change authors to integrate it, then I argue that overall it's a 
net loss to the core development.

Now you'll argue that the Seamonkey project should just have other people (not 
involved in core development) to handle integration, but in practice if you 
break the software people are using for day-to-day work they'll drop everything 
else and fix it, if they can.  So as long as core developers (in the sense of 
people who spend the bulk of their time on XULRunner development) are using 
trunk versions of non-Firefox apps (also known as exercising non-Firefox parts 
of the platform in a real user scenario, something we don't have enough of) we 
have a problem.

-Boris

Benjamin Smedberg schrieb:
> Just gently pushing them to develop self-sufficient communities
> that have a good working relationship with the core mozilla community.

Erm, I think you want to push some communities into some place they are 
already in to a great extent. I know quite a few people from "the 
SeaMonkey community" which happen to be help with the "Mozilla core" in 
many ways, and/or are even considered part of "the core Mozilla community".
I just hope it will stay as easy as it is currently for them to be 
members of both communities (actually I consider all those just to be 
some groups inside the big Mozilla community family). And I hope they 
can continue to use the "Mozilla core" they help develop through the 
SeaMonkey application just as they do now.

Robert Kaiser

Axel Hecht wrote:
> Benjamin Smedberg wrote:
>>
>> I think we need to be careful here. The primary consumer of our 
>> "platform"
>> is web developers. The extent to which we consider the needs of XPCOM+XUL
>> applications depends on their alignment with the goal of improving the 
>> web
>> and promoting open standards. Mozilla2 is focusing on improving the 
>> layout
>> (box model and templates), interactive support (native/UI theming), and
>> extensibility (XBL and overlays) of the web (HTML). Plus of course the
>> vastly improved language support that will be JS2. Providing a stable and
>> supported XUL language or XPCOM APIs is a secondary goal or even a 
>> non-goal.
> 
> Benjamin, just redefining what platform is is bad. I'm not going to 
> follow you, and I do strongly hope you drop it. What you're essentially 
> doing is stealing language from the community, which means, you're 
> taking away the means with which everything that is not just Firefox can 
> contribute to Mozilla 2. Statements like this really build up a barrier 
> for absolutely no value.

It seems to me that this isn't about an arbitrary redefinition of the 
use of the word "platform" in the Mozilla community.  Instead, it's a 
reflection of the fact that various people's thinking about what 
platform means, which parts are most important, and why, has evolved 
over time.  The fact that not everyone's thinking has evolved in perfect 
sync is a normal function of group behavior, I'll assert.

It strikes me that once upon a time, platform referred almost entirely 
to the XUL/XPCOM/XULRunner style platform.  With the rise of AJAX apps, 
people have also started to talk about the Web as a platform, and 
Firefox + extensions is sometimes spoken of as a platform as well.

So we've got, to some degree, three heavily overlapping platforms. 
Different community members are likely to prioritize them differently, 
but having discussions about what should drive overall prioritization 
seems healthier than "just dropping it".

Dan

Boris Zbarsky wrote:

>> Providing a stable and
>> supported XUL language or XPCOM APIs is a secondary goal or even a
>> non-goal.
> 
> I think as a blanket statement that's a sever mistake.  Providing
> improved security for XUL apps and extensions _is_ a goal, for example.

Yeah, I was being too severe. How does this sound: improving HTML and
standards are goals are intrisic to our mission. Improving XUL and our XPCOM
platform are goals because they help improve our opportunity and leverage
(with Firefox).

> That said, I'm curious.  When and where did the goals discussion for
> Mozilla 2 happen?  Did I miss it somehow?

It's happening. Please note that my posts are my own opinions and are not
intended to represent "mozilla 2" or brendan. Though they do influence how I
approach ownership of both toolkit and the build system.

> What is your definition of "core mozilla community" here?
> 
> From where I sit, there is significant overlap in terms of people
> between, say, the "Seamonkey community" and what I would consider the
> "core mozilla community".  But maybe you're using different definitions?
> 
> And maybe I'm having a knee-jerk reaction to narrow definitions of
> "core" and "external" from back in 2000 or so....  But maybe not.

Let me define "community" as "a group of people working towards common
goals". Now, I think we have many overlapping communities within the mozilla
ethosphere:

* The Firefox community: making Firefox a better web browser (user-centric,
primarily)

* the mozilla platform community: implementing web standards better and
pushing the web forward (web-developer-centric, primarily)

* The SeaMonkey community: making SeaMonkey a better suite

* The Thunderbird community: making Thunderbird a better
mailreader/communicator/whatever it actually is

* Other communities: e.g. songbird/democracy/joost/NVU using our XUL+XPCOM
platform to make rich client apps

And as much as I hate to say it, I really don't think there is a community
around our XUL/XPCOM/XULRunner platform itself. That is, there aren't really
any shared goals, other than the overlapping goals of the various
communities above.

There is nothing to say that somebody can't be part of more than one
community (e.g. have more than one goal). And there's certainly nothing
saying the communities can't work together. The roadmap (brendan/MoFo) have
identified that the goals that are most important are Firefox and the
mozilla platform. These define the communities which are most important, and
the technical direction when there is conflict between communities.

>> I think SeaMonkey and Thunderbird need to be in the same status as
>> Songbird:
>> there should no longer be a special entitlement or tinderbox tree
>> rules that
>> require mozilla developers to spend time on those products if it does not
>> make sense to do so.
> 
> How are we determining when it makes sense to do so?

I would rely on common sense, courtesy, and knowing the people involved. It
doesn't sound like something that can be legislated.

> Now you'll argue that the Seamonkey project should just have other
> people (not involved in core development) to handle integration, but in
> practice if you break the software people are using for day-to-day work
> they'll drop everything else and fix it, if they can.  So as long as
> core developers (in the sense of people who spend the bulk of their time
> on XULRunner development) are using trunk versions of non-Firefox apps
> (also known as exercising non-Firefox parts of the platform in a real
> user scenario, something we don't have enough of) we have a problem.

That very well could be true, but my experience has been that simply
*building* the three main apps in various "supported" configurations on
three platforms is a massive time sink. I have high hopes that we will be
able to converge on a common xulrunner core (and even build apps off a
common SDK download), but in the meantime the lagtime between finishing any
significant build system patch and checking it in is measured in weeks,
which is IMO not flexible enought to make the kinds of changes we need to
make (e.g. the common XULRunner mentioned above!).

--BDS

On Apr 6, 9:13 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
> Benjamin Smedberg wrote:
> > Providing a stable and
> > supported XUL language or XPCOM APIs is a secondary goal or even a non-goal.
>
> I think as a blanket statement that's a sever mistake.  Providing improved
> security for XUL apps and extensions _is_ a goal, for example.

Agreed about security. But Benjamin said "Providing ... stable and
supported ... *APIs*" and you wrote "Providing improved security" --
the two are not the same or coterminous.

I'm sure I don't agree with everything your or Benjamin thinks. Don't
panic! The goals of Mozilla 2 so far have been laid out in my blog and
the wiki. We will evolve and fill in details as we go. The important
point is that we are not going to preserve API compatibility where it
pays to break it (and we are going to break ABI compat).
Prioritization of APIs and underlying implementation work will be an
ongoing effort, and discussion.

> That said, I'm curious.  When and where did the goals discussion for Mozilla 2
> happen?  Did I miss it somehow?

You're soaking in it.

The high order bits are few: JS2 on Tamarin, Oink-based refactoring/
transformation, and competitive if not ground-breaking embedding/
layout/graphics "performance" (source approachability, clean if not
standard APIs, memory footprint, benchmark performance).

The anti-constraints are: API compat, ABI compat, build-all-or-many-
XUL-apps-at-once-as we go.

I'll let Benjamin field the rest. It's important not to freak out over
disjunctive or even wrong language by any principal hacker. We're all
approaching the same problem-space with, I think, shared values (I
include sipaq and myself here). If I'm wrong and someone active in the
community really thinks we should not do Mozilla 2 with the given
goals and non-goals, they have yet to say so.

/be

/be

brendan@mozilla.org schrieb:
> On Apr 6, 9:13 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
>> That said, I'm curious.  When and where did the goals discussion for Mozilla 2
>> happen?  Did I miss it somehow?
> 
> You're soaking in it.
> 
> The high order bits are few: JS2 on Tamarin, Oink-based refactoring/
> transformation, and competitive if not ground-breaking embedding/
> layout/graphics "performance" (source approachability, clean if not
> standard APIs, memory footprint, benchmark performance).

I hope a better localization infrastructure grows into being one of the 
important goals there as well (which again probably means breaking 
consumers of our old infrastructure).

Robert Kaiser

Benjamin Smedberg wrote:
> Yeah, I was being too severe. How does this sound: improving HTML and
> standards are goals are intrisic to our mission. Improving XUL and our XPCOM
> platform are goals because they help improve our opportunity and leverage
> (with Firefox).

Yes, but I'm not sure that "with Firefox" is necessarily the right tag end 
there.  ;)

> It's happening. Please note that my posts are my own opinions

They were phrased as statements of fact, not as opinions.  My apologies for not 
realizing that they did not represent some sort of consensus on the part of some 
group.  That's certainly the way they came across.

> Let me define "community" as "a group of people working towards common
> goals". Now, I think we have many overlapping communities within the mozilla
> ethosphere:

Agreed with this and the list.

> And as much as I hate to say it, I really don't think there is a community
> around our XUL/XPCOM/XULRunner platform itself.

Again, agreed.

>>> require mozilla developers to spend time on those products if it does not
>>> make sense to do so.
>> How are we determining when it makes sense to do so?
> 
> I would rely on common sense, courtesy, and knowing the people involved. It
> doesn't sound like something that can be legislated.

That's actually more or less where we are right now with the tree rules... At 
least in practice, for the components I deal with.

I accept that your experience with the build system may be different.

> That very well could be true, but my experience has been that simply
> *building* the three main apps in various "supported" configurations on
> three platforms is a massive time sink.

Absolutely.  Though with ccache it's not too bad.  Last I checked, once we build 
layout once for one of the three apps we're pretty good on the other two. 
Doesn't help much with Windows, I know.

>I have high hopes that we will be
> able to converge on a common xulrunner core

Yes, that would be ideal... and perhaps I should have made it clear that my 
arguments for how the Mozilla2 tree rules should work are predicated on the 
assumption that this has happened.  Or rather, only apps that use said common 
xulrunner core should even be considered for the current seamonkey/tbird tree 
rules.  Anything else would be a waste of time, I agree.

Once again, as I said to Brendan, I agree that we need looser rules in the near 
term (up to a year from now, probably).  Then we need to tighten them up, imo.

-Boris

brendan@mozilla.org wrote:
>> Benjamin Smedberg wrote:
>>> Providing a stable and
>>> supported XUL language or XPCOM APIs is a secondary goal or even a non-goal.
>> I think as a blanket statement that's a sever mistake.  Providing improved
>> security for XUL apps and extensions _is_ a goal, for example.
> 
> Agreed about security. But Benjamin said "Providing ... stable and
> supported ... *APIs*" and you wrote "Providing improved security" --
> the two are not the same or coterminous.

True, but part of what I look forward to in Mozilla2 are improvements in the 
APIs we expose to extensions to make them more secure by default.  That is, we 
should make it very difficult to shoot yourself in the foot, whereas right now 
it's very easy.

>> That said, I'm curious.  When and where did the goals discussion for Mozilla 2
>> happen?  Did I miss it somehow?
> 
> You're soaking in it.

See my response to bsmedberg.  ;)

> The high order bits are few: JS2 on Tamarin, Oink-based refactoring/
> transformation, and competitive if not ground-breaking embedding/
> layout/graphics "performance" (source approachability, clean if not
> standard APIs, memory footprint, benchmark performance).

I would like to suggest adding "core APIs designed for security from the ground 
up instead of having security bolted on" to this list...

> I'll let Benjamin field the rest. It's important not to freak out over
> disjunctive or even wrong language by any principal hacker.

Nothing to freak out about if said hacker is just presenting his own thoughts, 
not a fait accompli decision.  :)

Again, thank you for cutting through the confusion,

-Boris

brendan@mozilla.org wrote on 06. Apr 2007

> I'll let Benjamin field the rest. It's important not to freak out 
> over disjunctive or even wrong language by any principal hacker.

You're right. It's just hard not to freak out, when an importan
Mozilla hacker like Benjamin makes some harsh statements and it'
unclear to some, whether these statements are somewhat official o
just a personal opinion

I'm glad that this has been sorted out

Let me add, that since this discussion started from a director
list proposal, it would be beneficial IMO if you could blog abou
the main goals of mozilla2 and its possible downsides in context
so that everyone is on the same page regarding mozilla2

Frankly I don't think that everyone is yet, judging from the numbe
of participants here and the lack of mozilla2 discussions elsewhere

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

Robert Kaiser wrote:
> I hope a better localization infrastructure grows into being one of the 
> important goals there as well (which again probably means breaking 
> consumers of our old infrastructure).

The candidate is L10n (http://wiki.mozilla.org/L20n), right?

/be

Brendan Eich wrote:
> Robert Kaiser wrote:
>> I hope a better localization infrastructure grows into being one of 
>> the important goals there as well (which again probably means breaking 
>> consumers of our old infrastructure).
> 
> The candidate is L10n (http://wiki.mozilla.org/L20n), right?

See? I wrote L10n meaning L20n. This is going to hurt my fingers...

/be

Brendan Eich wrote:
> Brendan Eich wrote:
>> Robert Kaiser wrote:
>>> I hope a better localization infrastructure grows into being one of 
>>> the important goals there as well (which again probably means 
>>> breaking consumers of our old infrastructure).
>>
>> The candidate is L10n (http://wiki.mozilla.org/L20n), right?
> 
> See? I wrote L10n meaning L20n. This is going to hurt my fingers...
> 
> /be

It hurts both ways around, I can tell you. I never get the right one, in 
particular when I'm switching my mind from future work to daily back and 
forth.

I deserve it, I guess ;-)

Axel

Brendan Eich schrieb:
> Robert Kaiser wrote:
>> I hope a better localization infrastructure grows into being one of 
>> the important goals there as well (which again probably means breaking 
>> consumers of our old infrastructure).
> 
> The candidate is L10n (http://wiki.mozilla.org/L20n), right?

Right, L20n it is.

And I hope we'll get that working as soon as we can in Mozilla2, 
actually (by whatever name, but that's the only one we have right now).

Robert Kaiser

Simon Paquet wrote:
> The comments from the Calendar devs that I spoke with generally went
> into the direction of "MoCo did not, does not and never will care
> about us, it cares and will always care only about Firefox".

Although a bit late, I would like to comment on this. I indeed said 
something in that direction, but I didn't mean to say that MoCo does 
totally not care about calendar. They do care, given that there are 
tinderboxen, bugzilla components, ftp space etc. But calendar has never 
been a first-class product. And I don't expect it to be. After all, it's 
much smaller.
And that's what I meant: calendar was never a first class product, and 
likely won't be in the near future. So the situation stays the same for 
calendar.

That said, I would really love it if MoCo would spend more money on 
calendar. I think it is an important product, and having moco people 
work on it would be good. But that's a business decision for them to 
make, not for me.


Michiel

Michiel van Leeuwen wrote on 08. Apr 2007

>> The comments from the Calendar devs that I spoke with generally 
>> went into the direction of "MoCo did not, does not and never 
>> will care about us, it cares and will always care only about 
>> Firefox".
> 
> Although a bit late, I would like to comment on this. I indeed 
> said something in that direction, but I didn't mean to say that 
> MoCo does totally not care about calendar. They do care, given 
> that there are tinderboxen, bugzilla components, ftp space etc. 
> But calendar has never been a first-class product. And I don't 
> expect it to be. After all, it's much smaller.
> And that's what I meant: calendar was never a first class product, 
> and likely won't be in the near future. So the situation stays the 
> same for calendar.

Sorry for misunderstanding you

> That said, I would really love it if MoCo would spend more money 
> on calendar. I think it is an important product, and having moco 
> people work on it would be good.

To be fair, MoCo already paid people to work on Calendar code for 
short time. Dmose was paid to work on Calendar and lilmatt was hire
as a contractor and was allowed to work on Calendar code

Unfortunately dmose's duties lie now exclusively in the Firefo
space and lilmatt's contract expired and he now works for Flock
where he can no longer work full-time on Calendar code

You already know all of this, mvl, I'm adding this just as contex
for other interested readers

> But that's a business decision for them to make, not for me.

Looking at this discussion, I get the impression that MoCo is mor
and more focussing entirely on Firefox and moving away from its 2n
product Thunderbird. Therefore I do not expect any significan
investment into Calendar, as this would not match with MoCo's strateg
(as I perceive it)

All in all this is quite understandable from a business perspectiv
as there are always more people to hire, than money to pay them

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

Axel Hecht wrote:
  > It hurts both ways around, I can tell you. I never get the right 
one, in
> particular when I'm switching my mind from future work to daily back and 
> forth.

Then change the name, before it's too late :-)

Gerv

brendan@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:
>   

Sorry for jumping late into the discussion, I don't have time to follow 
blogs.

May I request that you import *all* of the Mozilla code in the new repo. 
Maybe you want to *use* only parts of it, but a decent VCS will allow 
that. I would think that importing would be easier, too, then - you 
import the old CVS wholesale, and do the merging between the import and 
new trunk branch - you probably do that anyways, so the only difference 
is that you don't ignore at import time, but at merge time.

I think that's extremely important, to keep the existing code in any new 
repo that is being created. Otherwise, it would be essentially lost. The 
burden for "rescueing" it, i.e. importing from CVS to a new repo (either 
the main one or a separate one) would be on the part of those who are 
interested in the other code, and most people would not bother. I think 
it's critically important to have all the code *readily* available for 
viewing and merging, when wanted, even in the future.

I can't really see much of a disadvantage for having a branch for "old" 
code in the new repo. And the code is what we all worked so hard on.

On a related, but not identical matter, I also think that all 
mozilla.org code should stay in the same repo. Even if all I have to do 
is to import another URL, it's something that everybody fetching the 
code would have to do, I assume, and even that is too much of a hassle 
IMHO. Also, it means that what's currently considered core Mozilla code 
will no longer be, and the Mozilla community will be even more scattered 
than it is now.

I think this is a really important matter for the future. What is going 
to be considered Mozilla code, and what happens with our old code and 
the code that won't be imported to the new repo? I think that the answer 
"whoever cares about it can make a new repo and import it there and work 
from there - that's easy with hg" will mean that most of the code will 
be essentially lost.

Ben Bucksch schrieb:
> May I request that you import *all* of the Mozilla code in the new repo. 

They won't do that. The plan is to split up the code into several 
similar, but separated repositories for Mozilla2. That is to a certain 
part because of the fact that working with a distributed VCS means that 
you have a copy of *the whole* repository on your machine when working 
with it, and separate, modular repositories make it possible to have 
only the parts of code you really need.

This has good and bad sides - if you read the whole thread here, you'll 
see many of those mentioned in the discussion.

Robert Kaiser

Robert Kaiser wrote:
> Ben Bucksch schrieb:
>> May I request that you import *all* of the Mozilla code in the new repo. 
>
> They won't do that. The plan is to split up the code into several 
> similar, but separated repositories for Mozilla2.

That's fine. There should just be *a* repository which still has *all* 
the old code, as hg repo, so that it's trivially accessible. If somebody 
has to start a repository conversion or an import from a foreign repo, 
nobody will do that and the code will just die. That's not good, because 
there are thousands of man-years in there.

Ben

James Ross wrote:
> The Mozilla 2 repository is not meant to build anything except 
> XULRunner and Firefox, at least for now, and until the location of any 
> suite-only items is decided (assuming that is to move at all) there 
> should be no reason to move/clone things like ChatZilla or Venkman.

OK, so where are they going? Do has the burden of importing them in the 
new format?

Doing it all-at-once should not be that hard, 30 people each having to 
do it for their own project will be very time-consuming, overall.

Ben Bucksch wrote:
> Robert Kaiser wrote:
>> Ben Bucksch schrieb:
>>> May I request that you import *all* of the Mozilla code in the new repo. 
>>
>> They won't do that. The plan is to split up the code into several 
>> similar, but separated repositories for Mozilla2.
> 
> That's fine. There should just be *a* repository which still has *all* 
> the old code, as hg repo, so that it's trivially accessible. If somebody 
> has to start a repository conversion or an import from a foreign repo, 
> nobody will do that and the code will just die. That's not good, because 
> there are thousands of man-years in there.
> 
> Ben

Wait... are you trying to argue everybody except the Firefox developers 
will neglect to import their stuff into hg and will hence start from 
scratch or drop their project? Because that's what you seem to be 
claiming, and I'll call "bs" on that. Seriously.

Also, "all the old code" as an hg repo is very much not trivial, per the 
numerous blogposts on this subject. In fact, it might well be a lot more 
trivial to make smaller hg repos for all the bits of code separately, so 
people don't have to worry about everything else in the old repo that 
they really don't want to be worrying about - ie, calendar people not 
having to care about mailnews branching problems, or seamonkey people 
not being miffed about thunderbird tags.

~ Gijs

Gijs Kruitbosch wrote:
> Ben Bucksch wrote:
>> That's fine. There should just be *a* repository which still has 
>> *all* the old code, as hg repo, so that it's trivially accessible. If 
>> somebody has to start a repository conversion or an import from a 
>> foreign repo, nobody will do that and the code will just die. That's 
>> not good, because there are thousands of man-years in there.
>>
>> Ben
>
> Wait... are you trying to argue everybody except the Firefox 
> developers will neglect to import their stuff into hg and will hence 
> start from scratch or drop their project? Because that's what you seem 
> to be claiming, and I'll call "bs" on that. Seriously.

Yes, I'm claiming that, at least for some code parts. I have wrote at 
least one extension in the Mozilla tree that I have no interest in any 
more and that has no current maintainer. That doesn't mean the code 
should just go to trash.
The same is probably true for other parts.

The other claim I make is that it takes 2 days for one person to import 
everything at once, and it takes half a day or one day for each module 
owner to figure out how to import correctly between two version control 
systems - a far from trivial task (I have done that for many systems, 
can be a *real* pain, even with instructions). So, that's 2 days vs. 50 
days (assuming 50-100 modules).

> Also, "all the old code" as an hg repo is very much not trivial, per 
> the numerous blogposts on this subject.

How is it any harder to just take all the Mozilla code (or at least 
everything that you checkout when you check out MOZ_CO_PROJECT=all or 
whatever) and put that into a hg repo than to cherry-pick just the 
Firefox and xulrunner stuff?

> so people don't have to worry about everything else in the old repo 
> that they really don't want to be worrying about - ie, calendar people 
> not having to care about mailnews branching problems, or seamonkey 
> people not being miffed about thunderbird tags.

If a working repo for all projects is to hard, then at least have an 
archive repo. But as hg repo, so that it integrates nicely, and you can 
use that as branch source for your own repo.

-- 
When responding via mail, please remove the ".news" from the email address.

Ben Bucksch schrieb:
> If a working repo for all projects is to hard, then at least have an 
> archive repo. But as hg repo, so that it integrates nicely, and you can 
> use that as branch source for your own repo.

The archive for old code is cvs.m.o, which will be kept alive with the 
1.x code, including olde branches that aren't even imported into the 
Mozilla2 repository (collection).

Robert Kaiser

brendan@mozilla.org wrote:

>browser
>  
>
Apparently it's no longer enough to pull the tip, you now have to pull 
the entire history of the "branch" you're working on. Will there be a 
way for people to avoid pulling components they don't want?

-- 
Warning: May contain traces of nuts.

Neil schrieb:
> brendan@mozilla.org wrote:
> 
>> browser
>>  
>>
> Apparently it's no longer enough to pull the tip, you now have to pull 
> the entire history of the "branch" you're working on. Will there be a 
> way for people to avoid pulling components they don't want?

Apparently not. That's the reason why splitting up into those into 
separate, smaller repositories is the proposal here, and probably the 
way to go, so you only need to pull the repositories for those 
components you actually need.

Robert Kaiser

Robert Kaiser wrote:
> Ben Bucksch schrieb:
>> If a working repo for all projects is to hard, then at least have an 
>> archive repo. But as hg repo, so that it integrates nicely, and you 
>> can use that as branch source for your own repo.
>
> The archive for old code is cvs.m.o

Please read the quote again. Thanks.

-- 
When responding via mail, please remove the ".news" from the email address.

Robert Kaiser wrote:
> Ben Bucksch schrieb:
>> If a working repo for all projects is to hard, then at least have an 
>> archive repo. But as hg repo, so that it integrates nicely, and you 
>> can use that as branch source for your own repo.
> 
> The archive for old code is cvs.m.o, which will be kept alive with the 
> 1.x code, including olde branches that aren't even imported into the 
> Mozilla2 repository (collection).
> 
> Robert Kaiser

Will this Mozilla 2 repository impact the way people like me build 
SeaMonkey v1.5?

Michael Vincent van Rantwijk, MultiZilla schrieb:
> Robert Kaiser wrote:
>> Ben Bucksch schrieb:
>>> If a working repo for all projects is to hard, then at least have an 
>>> archive repo. But as hg repo, so that it integrates nicely, and you 
>>> can use that as branch source for your own repo.
>>
>> The archive for old code is cvs.m.o, which will be kept alive with the 
>> 1.x code, including olde branches that aren't even imported into the 
>> Mozilla2 repository (collection).
> 
> Will this Mozilla 2 repository impact the way people like me build 
> SeaMonkey v1.5?

No, Gecko 1.9 will be released off the current CVS system, and SeaMonkey 
1.5 or 2.0 (whatever we will call the Gecko-1.9-based release) will be 
released off that CVS system as well, just as with the current 
1.8.x-based releases.

The change in VCS hosting will only be for Mozilla2, which is for way 
beyond Gecko 1.9 and FF3, TB3 or the next major SeaMonkey release 
("suiterunner").

Robert Kaiser

Robert Kaiser schrieb:
> brendan@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 git@vger.kernel.org which I glanced on a few 
> times via gmame.

http://lilypond.org/git/binaries/mingw/ nowadays has installers for 
MinGW git, BTW - just as a note for anyone interested in testing it for 
his own use, I don't want to warm up this discussion for Mozilla2.

Robert Kaiser