Mozilla 2 repository migration dirlist
bre...@mozilla.org
subdirectories in the case of directories, from under
cvs.mozilla.org's mozilla top-level directory, that I propose we
migrate into the Mozilla 2 initial repository:
Makefile.in
LICENSE
LEGAL
README.txt
accessible
aclocal.m4
allmakefiles.sh
browser
build
caps
chrome
config
configure.in
client.mk
content
db
dbm
docshell
dom
editor
embedding
extensions/Makefile.in
extensions/access-builtin
extensions/auth
extensions/canvas3d
extensions/cck
extensions/cookie
extensions/datetime
extensions/finger
extensions/gnomevfs
extensions/inspector
extensions/java
extensions/jssh
extensions/layout-debug
extensions/metrics
extensions/negotiateauth
extensions/permissions
extensions/pref
extensions/python
extensions/reporter
extensions/spellcheck
extensions/universalchardet
gfx
intl
ipc
jpeg
js
layout
modules
netwerk
nsprpub
other-licenses
parser
plugin
profile
rdf
security
storage
sun-java
testing
themes
toolkit
tools
uriloader
view
webshell
widget
xpcom
xpfe
xpinstall
xulrunner
See http://wiki.mozilla.org/Mozilla2 for more. The initial repository
will be a Mercurial one, but don't panic. We need to get to work on
Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
repository solution to emerge. We'll start with hg, and reconsider bzr
if it speeds up enough. See preed's blog for why we can't use git or
other contenders and wannabes.
Also do not panic about the above list leaving out mail, mailnews,
composer, calendar, camino, etc. Mozilla 2 needs focus and the
repository can grow. Or, with better VCSes such as hg, we can have
several repositories. With better embedding APIs we won't want to
tightly couple source of a given XUL app to source of a given Gecko
back end file. But we will want to keep Firefox and XULRunner building
at all times. So the above list does include those two.
Comments welcome, but we are likely to create this soon. Useful
comments would be "don't forget xyzzy or you can't build foopy", not
"why aren't you importing electricalfire" or the like.
Thanks to Benjamin for help getting this list right (jst and pav too).
/be
Gijs Kruitbosch
> 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:
>
> xpfe
> <snip>
>
> See http://wiki.mozilla.org/Mozilla2 for more. The initial repository
> will be a Mercurial one, but don't panic. We need to get to work on
> Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
> repository solution to emerge. We'll start with hg, and reconsider bzr
> if it speeds up enough. See preed's blog for why we can't use git or
> other contenders and wannabes.
>
> Also do not panic about the above list leaving out mail, mailnews,
> composer, calendar, camino, etc. Mozilla 2 needs focus and the
> repository can grow. Or, with better VCSes such as hg, we can have
> several repositories. With better embedding APIs we won't want to
> tightly couple source of a given XUL app to source of a given Gecko
> back end file. But we will want to keep Firefox and XULRunner building
> at all times. So the above list does include those two.
>
> Comments welcome, but we are likely to create this soon. Useful
> comments would be "don't forget xyzzy or you can't build foopy", not
> "why aren't you importing electricalfire" or the like.
>
> Thanks to Benjamin for help getting this list right (jst and pav too).
>
> /be
>
It's my understanding that xpfe is currently only used by the Suite, and
they're moving away from it. Could someone explain why it is in this
list, then? (My apologies for any ignorance demonstrated - I suppose I'm
just curious)
-- Gijs
Eli Friedman
> It's my understanding that xpfe is currently only used by the Suite, and
> they're moving away from it. Could someone explain why it is in this
> list, then? (My apologies for any ignorance demonstrated - I suppose I'm
> just curious)
>
> -- Gijs
I believe Firefox still depends on some code in xpfe, including
xpfe/appshell.
-Eli
bre...@mozilla.org
> It's my understanding that xpfe is currently only used by the Suite, and
> they're moving away from it. Could someone explain why it is in this
> list, then? (My apologies for any ignorance demonstrated - I suppose I'm
> just curious)
(I replied via email to Gijs already, but for the record:)
xpfe is pulled and built when building Firefox, at least parts of it
are. We don't propose to "fix" this before starting the Mozilla 2
migration.
BTW, in case it's not clear from the wiki docs and my origina Mozilla
2 blog, we will of course use the new repository's better branching
and merging to automate merges from the 1.9 CVS trunk into the Hg
repo, probably nightly to a copy of the trunk. From that, we'll
maintain a branch that periodically, based on known-good 1.9 status,
merges 1.9 and Mozilla 2. As noted in my blog, we anticipate many
experimental branches (for Tamarin work, Oink/Elsa-based refactoring,
etc.) and related integration branches feeding back into the main
Mozilla 2 branch.
In the course of the next few months, we should also find it easier in
Hg to rename and remove things, including xpfe if we can (sun-java
too). So Gijs' point is well taken.
/be
Gervase Markham
> nsprpub
What are the plans for taking releases of NSPR and NSS, as they are
released by their respective teams? You probably don't want to just
import the trunk versions of these two directories.
> other-licenses
All of it? I think you could do without, at least, libart_lgpl and libical.
> security
Again, there are directories in here ("svrcore"?) which you may not need.
> tools
Is there not an unnecessary accidental forkage risk here? Yes, we can
merge stuff across, and perhaps the set of people working on stuff in
here is small enough that it won't matter, but it might make sense to
just keep these in one place or the other, as many aren't build
dependencies.
> widget
Again, all of them?
Hope those are useful comments.
Gerv
Neil
> bre...@mozilla.org wrote:
>
>> widget
>
> Again, all of them?
Most of them, I would have thought... but under gfx you probably only
need cairo/thebes, right?
--
Warning: May contain traces of nuts.
T Rowley
> See http://wiki.mozilla.org/Mozilla2 for more. The initial repository
> will be a Mercurial one, but don't panic. We need to get to work on
> Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
> repository solution to emerge. We'll start with hg, and reconsider bzr
> if it speeds up enough. See preed's blog for why we can't use git or
> other contenders and wannabes.
Who is going to be doing this work concurrent with 1.9? All the core
developers I'm aware of have their plates full getting 1.9 into
shippable form.
Benjamin Smedberg
>> tools
>
> Is there not an unnecessary accidental forkage risk here? Yes, we can
> merge stuff across, and perhaps the set of people working on stuff in
> here is small enough that it won't matter, but it might make sense to
> just keep these in one place or the other, as many aren't build
> dependencies.
There will be no forking. The Hg repository will be periodically (at least
once a day) re-imported from CVS. Somebody from the mozilla2 team will do
merging if necessary.
--BDS
Benjamin Smedberg
> It's my understanding that xpfe is currently only used by the Suite, and
> they're moving away from it. Could someone explain why it is in this
> list, then? (My apologies for any ignorance demonstrated - I suppose I'm
> just curious)
xpfe/ is a wasteland of code built by various apps. Some of it is in the
platform (xpfe/appshell), some of it is inconveniently shared between
firefox and seamonkey (xpfe/components/...). We are gradually working
towards moving everything out of xpfe/ to an appropriate module, but for the
time being it is needed.
--BDS
Benjamin Smedberg
>> nsprpub
>
> What are the plans for taking releases of NSPR and NSS, as they are
> released by their respective teams? You probably don't want to just
> import the trunk versions of these two directories.
I'm not sure yet whether we'll be importing trunk or the client branch/tags
of these. And I do believe the goal is to have these in their own repository
at some point.
>> other-licenses
>
> All of it? I think you could do without, at least, libart_lgpl and libical.
I'll work on separating this out a bit more.
>> widget
>
> Again, all of them?
I don't see any need to be more granular. Obviously there is old/unsupported
code there, but it's inconsequential and can be remove later at our leisure.
--BDS
Robert Kaiser
> See http://wiki.mozilla.org/Mozilla2 for more. The initial repository
> will be a Mercurial one, but don't panic. We need to get to work on
> Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
> repository solution to emerge. We'll start with hg, and reconsider bzr
> if it speeds up enough. See preed's blog for why we can't use git or
> other contenders and wannabes.
I see no recent comment on that, and given that reportedly the only real
argument against git is/was that almost half a year ago there was no
well-performing win32 port. This reportedly has changed, so despite some
people telling "git is no option" without bringing forward any current
argument, I think it should be re-evaluated as a third possible choice.
From what I hear, it probably has the most vibrant dev community of all
those choices and works well with a few quite big (in code and community
size) projects - and I tend to think that's something that has value for
Mozilla as well.
> Also do not panic about the above list leaving out mail, mailnews,
> composer, calendar, camino, etc. Mozilla 2 needs focus and the
> repository can grow. Or, with better VCSes such as hg, we can have
> several repositories. With better embedding APIs we won't want to
> tightly couple source of a given XUL app to source of a given Gecko
> back end file. But we will want to keep Firefox and XULRunner building
> at all times. So the above list does include those two.
Well, this means that people working on anything else than Firefox will
probably just not care about that Mozilla2 repo as they can't build
their stuff with/from it. That may be intended, but it creates a major
split within the Mozilla dev community (the privileged who can use
Mozilla2, and the dumb rest that is more or less closed out from it and
whose wishes/bugs/problems won't be looked at a lot there). I'm not sure
this is a good thing to do.
In my eyes, reducing the amount of code managed by the repo just tells
that the new VCS is not as capable as CVS of managing a huge codebase
like the one we have.
Robert Kaiser
Benjamin Smedberg
> Well, this means that people working on anything else than Firefox will
> probably just not care about that Mozilla2 repo as they can't build
> their stuff with/from it. That may be intended, but it creates a major
> split within the Mozilla dev community (the privileged who can use
> Mozilla2, and the dumb rest that is more or less closed out from it and
> whose wishes/bugs/problems won't be looked at a lot there). I'm not sure
> this is a good thing to do.
This is a natural continuation of the plans to separate the "core" from the
apps built on top of it. Firefox has a special place here because it is the
primary app used to test the core, and its primary driver.
All of our apps are going to be built on the xulrunner core in the moz2
timeframe, and the repository structure is just a natural extension of that
architecture.
--BDS
Gervase Markham
> This is a natural continuation of the plans to separate the "core" from the
> apps built on top of it. Firefox has a special place here because it is the
> primary app used to test the core, and its primary driver.
>
> All of our apps are going to be built on the xulrunner core in the moz2
> timeframe, and the repository structure is just a natural extension of that
> architecture.
If the idea is that every XULRunner app apart from Firefox is built by
pulling from 2 (or more) repositories - the core one and the
app-specific one - and combining the result, why not apply the same
logic to Firefox? It would mean that whatever magic is necessary to
perform such a combination is guaranteed to keep working. And it would
guarantee a clean interface between what was platform and what was not.
Gerv
bre...@mozilla.org
> On 3/27/07 11:40 PM, bren...@mozilla.org wrote:
>
> > Seehttp://wiki.mozilla.org/Mozilla2for more. The initial repository
> > will be a Mercurial one, but don't panic. We need to get to work on
> > Mozilla 2 concurrently with 1.9, and we can't wait for the perfect
> > repository solution to emerge. We'll start with hg, and reconsider bzr
> > if it speeds up enough. See preed's blog for why we can't use git or
> > other contenders and wannabes.
>
> Who is going to be doing this work concurrent with 1.9? All the core
> developers I'm aware of have their plates full getting 1.9 into
> shippable form.
That's why, as blogged and wiki'ed, we're starting with
deCOMtamination, DOM and Tamarin work. jst and I are joining tglek and
dsw on the first two; the Tamarin team, graydon, igor, and other
SpiderMonkey folks will join in due course.
We are going to do two things at once, for a change. This will require
more people. We have more now, and we are recruiting yet more.
/be
bre...@mozilla.org
> Benjamin Smedberg wrote:
> > This is a natural continuation of the plans to separate the "core" from the
> > apps built on top of it. Firefox has a special place here because it is the
> > primary app used to test the core, and its primary driver.
>
> > All of our apps are going to be built on the xulrunner core in the moz2
> > timeframe, and the repository structure is just a natural extension of that
> > architecture.
>
> If the idea is that every XULRunner app apart from Firefox is built by
> pulling from 2 (or more) repositories - the core one and the
> app-specific one - and combining the result, why not apply the same
> logic to Firefox?
Because that's a lot of work we don't need to do right now, and can't
afford to do right now. Mozilla 2 is already under way and it needs a
repository. We need working Firefox and XULRunner built on it.
> It would mean that whatever magic is necessary to
> perform such a combination is guaranteed to keep working. And it would
> guarantee a clean interface between what was platform and what was not.
There's no point in perfecting the separation of any given modules
before we start the Mozilla 2 repository. Nor must we do all that work
in the 1.9 time frame -- most of it fits in Mozilla 2 much better. We
are not going to spend all our time first cleaning up widget or gfx,
or removing nss and nsprpub to their own repos, etc. etc. Shaver keeps
attributing Voltaire's "best is the enemy of the good" to me, and what
did Voltaire know? But it fits here.
/be
bre...@mozilla.org
> I see no recent comment on that, and given that reportedly the only real
> argument against git is/was that almost half a year ago there was no
> well-performing win32 port. This reportedly has changed, so despite some
> people telling "git is no option" without bringing forward any current
> argument, I think it should be re-evaluated as a third possible choice.
> From what I hear, it probably has the most vibrant dev community of all
> those choices and works well with a few quite big (in code and community
> size) projects - and I tend to think that's something that has value for
> Mozilla as well.
Got a link to pages documenting this git windows work? jst uses git on
cvs today, he keeps up, he's a fan. It's not as if we have it in for
git.
> Well, this means that people working on anything else than Firefox will
> probably just not care about that Mozilla2 repo as they can't build
> their stuff with/from it. That may be intended, but it creates a major
> split within the Mozilla dev community (the privileged who can use
> Mozilla2, and the dumb rest that is more or less closed out from it and
> whose wishes/bugs/problems won't be looked at a lot there).
Nice false dilemma. But since we will give all committers access to
the new repo, and merge trunk changes into Mozilla 2, and keep API
compatibility where we want it (and in all cases, initially), it's
simply not true that anyone is locked out.
Having to host an app elsewhere from the core back end has its pluses
and minuses. It's already being done by the Flocks, Joosts, and
Songbirds of the world. It was done by chimera (camino) initially.
Tinderbox/buildbot coverage is independent of source hosting.
> I'm not sure
> this is a good thing to do.
It's a trade-off:
Pro: focus on Mozilla 2 APIs for Firefox and XULRunner; smaller pull;
more approachable repository (contrast to webkit).
Con: two repositories for other apps; feelings of a division among
apps and people.
If we can use features of the new VCS to host other apps in the new
repo but not obtrusively, we may consider using such features. But now
is not the time to worry about this, before we've committed any of the
automated refactoring patches taras is generating, or done any of the
other more bottom-up/back-to-front work for Moz2.
> In my eyes, reducing the amount of code managed by the repo just tells
> that the new VCS is not as capable as CVS of managing a huge codebase
> like the one we have.
There's no evidence for that.
/be
bre...@mozilla.org
wrote:
> It's a trade-off:
>
> Pro: focus on Mozilla 2 APIs for Firefox and XULRunner; smaller pull;
> more approachable repository (contrast to webkit).
As I noted in an earlier mail, it also reduces odds of unwanted
coupling to private or other APis.
> Con: two repositories for other apps; feelings of a division among
> apps and people.
Trade-off duality says: it makes it hard for other apps to use secret
APIs they might want to use; it raises the odds of Firefox or
XULRunner using such APIs (but that's arguably ok if other apps are
XULRunner based and do not need such APIs).
/be
Simon Paquet
> Well, this means that people working on anything else than Firefox
> will probably just not care about that Mozilla2 repo as they can't
> build their stuff with/from it. That may be intended, but it creates
> a major split within the Mozilla dev community (the privileged who
> can use Mozilla2, and the dumb rest that is more or less closed out
> from it and whose wishes/bugs/problems won't be looked at a lot
> there). I'm not sure this is a good thing to do.
The split can already be seen in various places and this is just a
consequent continuation of the actions that MoCo has taken in the past
months. It's pretty obvious that people there exclusively care for
Firefox (since it pays their bills and wages) and do not care a bit
about the rest of the Mozilla community.
I just wish that they would openly say so, and not try to tell people
otherwise or blind people's eyes with stuff like the manifesto, which
MoCo obviously has no intention to adhere to.
--
Simon Paquet
Sunbird/Lightning website maintainer
Project website: http://www.mozilla.org/projects/calendar
Developer blog: http://weblogs.mozillazine.org/calendar
Robert Kaiser
> git.
From what I've read, the MinGW port of git is working and performing
quite well, it has been started as a fork of mainline git but it is
intended to be merged upstream once someone comes around to introduce
the necessary #ifdefs to sort out what to compile where.
Bulding on MSYS and MinGW, it also would fit well with our targeted
Windows build infrastructure, I guess.
Main sources for this info are the gitweb page of the MinGW port
http://repo.or.cz/w/git/mingw.git as well as its README.MinGW
http://repo.or.cz/w/git/mingw.git?a=blob_plain;f=README.MinGW;hb=master
and the git mailing list g...@vger.kernel.org which I glanced on a few
times via gmame.
> Nice false dilemma. But since we will give all committers access to
> the new repo, and merge trunk changes into Mozilla 2, and keep API
> compatibility where we want it (and in all cases, initially), it's
> simply not true that anyone is locked out.
Well, locked out might be the wrong term. I just quite sure that many
people will just not care about the Mozilla2 repo if working with the
old CVS is not only what they're used to but also a lot easier, not
needing to set up multiple repositories etc.
This in turn will likely keep them away from Mozilla2 work, splitting
the project and removing them from the edge of development (even though
not directly _locking_ them away from it).
It might turn out completely differently, I'm just expressing what I
fear will come out of that.
> It's a trade-off:
>
> Pro: focus on Mozilla 2 APIs for Firefox and XULRunner; smaller pull;
> more approachable repository (contrast to webkit).
>
> Con: two repositories for other apps; feelings of a division among
> apps and people.
Or even more than two, when I think of someone wanting to build
Thunderbird+Lightning at once or even SeaMonkey+Lightning (normal
SeaMonkey can already run into problems with the mailnews backend being
shared with Thunderbird). And what about builds including Venkman or
Chatzilla?
This all is so easy to do with a big shared repository and can get very
complicated with splitted repositories, which makes quite reservated
about that approach.
Another thing is needing to pull a completely different repo just
because you want to help a different project and do a patch for them,
e.g. for webtools or such. With the current approach, the nice thing is
you can easily go, pull that dir in your trunk tree, hack a patch, post
it on bugzilla, check it in after appropriate reviews. Pulling lots of
different repositories in different dirs can easily get annoying enough
that people get scared away from such cross-project help.
> If we can use features of the new VCS to host other apps in the new
> repo but not obtrusively, we may consider using such features.
That would sound nice, but we probably first need to find out what is
easily possible and what not.
I don't want to tell that the approach is wrong, I just want to point
out possible problems we likely will come across, esp. if they hinder us
from getting an even better collaborating community.
Robert Kaiser
bre...@mozilla.org
> I just wish that they would openly say so, and not try to tell people
> otherwise or blind people's eyes with stuff like the manifesto, which
> MoCo obviously has no intention to adhere to.
Careful with the accusations of dishonesty or at least hypocrisy.
There's strong feeling here, but not much that's true. If we didn't
care about the platform for other apps, we would not take bugfixes,
even late in the cycle or considered for inclusion on a maintenance
branch, for bugs that don't affect Firefox. But we do (see, e.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=362564 or
https://bugzilla.mozilla.org/show_bug.cgi?id=176182).
There ain't no such thing as a free lunch. Firefox pays bills and
more: it creates a faster-moving ecosystem for addons and webapps that
don't face the formidable distribution challenges that XUL App #2
faces. Never mind that we have XUL App #2 (Thunderbird) and it faces
other challenges because *it's not the browser*. I'm not saying a
thick mail client should not be supported by the platform. I am saying
it's bound to place or show, not win. That means it will not
*necessarily* be included in the new repository.
Joost, Songbird, and Flock are not so hosted. Should they be, or our
manifesto talk is all lies? Of course if they were, we would be
accused of selling out to venture-funded startups. We'd have to host
every XUL app, on an equal footing, for some people to be happy.
But we're not going to make everyone happy. We're going to shrink and
speed up our codebase and move the web forward with the big lever,
Firefox, and the platform it's built on, which is codified as
XULRunner. I suggest you argue with facts and bug citations (if you
can find bugs where anyone shortchanged another XUL app without good
reason).
/be
Robert Sayre
>
> But we're not going to make everyone happy. We're going to shrink and
> speed up our codebase and move the web forward with the big lever,
> Firefox, and the platform it's built on, which is codified as
> XULRunner. I suggest you argue with facts and bug citations (if you
> can find bugs where anyone shortchanged another XUL app without good
> reason).
All bug citations of that sort, good or bad, are proof that there is a
non-zero coordination cost in the current CVS layout.
Firefox has the leverage to keep the Web open, so that's where the
resources go. It would be completely irresponsible to ignore that
leverage when making allocations. So, a centralized CVS repository comes
with a bureaucracy that must focus on Firefox for a variety of reasons,
and that harms other projects.
The point of switching to hg or bzr or git is to enable a mesh of
repositories rather than one single, lumbering monster. Brendan
correctly points out that this spread is already happening with Joost,
Flock, Zap et al. We need to make it easier. Wouldn't it be nice to pull
changes from XPCOM and Toolkit at will, without the need to negotiate
branch policies with Firefox drivers, and still be able to track the
rest of the repository sanely?
--Rob
bre...@mozilla.org
> bren...@mozilla.org wrote:
>
> > But we're not going to make everyone happy. We're going to shrink and
> > speed up our codebase and move the web forward with the big lever,
> > Firefox, and the platform it's built on, which is codified as
> > XULRunner. I suggest you argue with facts and bug citations (if you
> > can find bugs where anyone shortchanged another XUL app without good
> > reason).
>
> All bug citations of that sort, good or bad, are proof that there is a
> non-zero coordination cost in the current CVS layout.
I claim you can cite bugs that demonstrate we've taken patches that
have nothing to do with Firefox, even late in the release cycle. Which
falsifies what I read as Simon's contention that the manifesto is a
lie and we care only about Firefox.
You're right there are non-zero coordination costs -- no free lunch.
This should be, like, "duh" material. That it is not, or that everyone
wants *his* lunch for free, and screw the other guy and Firefox, is
the underlying problem in my view.
> Firefox has the leverage to keep the Web open, so that's where the
> resources go. It would be completely irresponsible to ignore that
> leverage when making allocations.
Yes, good point. You are more explicit than I was, but I said so by
talking about Thunderbird, which has millions of users.
> So, a centralized CVS repository comes
> with a bureaucracy that must focus on Firefox for a variety of reasons,
> and that harms other projects.
This is a good point too. I suspect many folks -- not all -- are
laboring under the limitations, assumptions, and working culture of
the CVS single master repository model.
> The point of switching to hg or bzr or git is to enable a mesh of
> repositories rather than one single, lumbering monster. Brendan
> correctly points out that this spread is already happening with Joost,
> Flock, Zap et al. We need to make it easier. Wouldn't it be nice to pull
> changes from XPCOM and Toolkit at will, without the need to negotiate
> branch policies with Firefox drivers, and still be able to track the
> rest of the repository sanely?
With better merge algs to boot!
/be
bre...@mozilla.org
wrote:
> On Mar 28, 9:51 am, Gervase Markham <g...@mozilla.org> wrote:
> > Benjamin Smedberg wrote:
> > > All of our apps are going to be built on the xulrunner core in the moz2
> > > timeframe, and the repository structure is just a natural extension of that
> > > architecture.
>
> > If the idea is that every XULRunner app apart from Firefox is built by
> > pulling from 2 (or more) repositories - the core one and the
> > app-specific one - and combining the result, why not apply the same
> > logic to Firefox?
>
> Because that's a lot of work we don't need to do right now, and can't
> afford to do right now. Mozilla 2 is already under way and it needs a
> repository. We need working Firefox and XULRunner built on it.
In addition to the expediency argument, it's clear to me that a dream-
world where the core XULRunner and Gecko code is in one repository,
and Firefox is in another, symmetric with respect to other XUL apps,
is just that: a dream world. I'd like to pick on Gerv's "why not apply
the same logic" question a bit more (he can take it ;-).
Firefox is not "just another XUL app". Mozilla would do a disservice
to everyone in its community, not just "end users", if it pretended
otherwise. Firefox and XULRunner/Gecko are the big lever we have to
advance the web. And with the right fulcrum, we may be able to move
mountains. We cannot treat all XUL apps equally in practice, even in
an ideal world. Practically speaking, we are willing to couple Firefox
to the back end, as it is today, via unfrozen APIs.
We aspire to freeze all such APIs. But if we don't succeed by any
given release (e.g., Firefox 4 on top of Mozilla 2), then we will
couple front to back end within the new repository.
/be
bre...@mozilla.org
[git news snipped]
We'll need to evaluate the situation, but we need to move now. We've
already delayed enough evaluating bzr. All these VCSes are moving
targets, and we can't keep trying the latest unmerged experiment or
port or we will never pick one and move. Again, we can switch later,
especially once we have moved to a changeset based system. It's
clearly wrong to say "we've picked the right system for the next ten
years". But (see below) it's also wrong to stick with CVS for Mozilla
2.
> > Nice false dilemma. But since we will give all committers access to
> > the new repo, and merge trunk changes into Mozilla 2, and keep API
> > compatibility where we want it (and in all cases, initially), it's
> > simply not true that anyone is locked out.
>
> Well, locked out might be the wrong term.
It is.
> I just quite sure that many
> people will just not care about the Mozilla2 repo if working with the
> old CVS is not only what they're used to but also a lot easier, not
> needing to set up multiple repositories etc.
Well, now you are changing your argument. If some users don't want
anything but CVS, they will indeed be stuck. But the Mozilla project's
future after 1.9 is Mozilla 2. cvs.mozilla.org will live forever, but
the main line of development, the place where sustained security bug-
fixing and rearchitecture, Tamarin integration, performance work,
embedding API that we can support, etc., will be the new repository.
It's silly to say "people will just use CVS because it's too hard to
use two VCSes" given this. If you believe we will fail at Mozilla 2,
say so. If you think there's something other than CVS that will favor
too many people in the community sticking with cvs.mozilla.org in
perpetuity, I'd like to hear what that something else might be.
> This in turn will likely keep them away from Mozilla2 work, splitting
> the project and removing them from the edge of development (even though
> not directly _locking_ them away from it).
Your argument now is that we can never move from CVS to a new VCS
because it would split the community. But that is false, given all the
folks already using new VCSes layered on top-of-trunk pulls from CVS.
And it ignores all the wins of the new VCSes, some of which are
necessary for Mozilla 2.
/be
Simon Paquet
>> I just wish that they would openly say so, and not try to tell
>> people otherwise or blind people's eyes with stuff like the
>> manifesto, which MoCo obviously has no intention to adhere to.
>
> Careful with the accusations of dishonesty or at least hypocrisy.
>
> There's strong feeling here, but not much that's true. If we didn't
> care about the platform for other apps, we would not take bugfixes,
> even late in the cycle or considered for inclusion on a maintenance
> branch, for bugs that don't affect Firefox. But we do (see, e.g.,
> https://bugzilla.mozilla.org/show_bug.cgi?id=362564 or
> https://bugzilla.mozilla.org/show_bug.cgi?id=176182).
There's a difference between caring about the platform all of the
time (and thereby adhering to the manifesto) or doing so only some
of the time, which is my impression.
Just to be clear, I'm *not* calling you or other people from MoCo
a huge bunch of liars, who are betraying the project. That wouldn't
be true. But I see more and more indications that the project is
moving from the "multitude of products with a premier app" point to
the "One premier app and a bunch of other stuff which we tolerate
unless it does not get in our way" point.
The first one is fine, the second one is not. This feels more and
more like the days, when Netscape dominated the project and alienated
more people than it helped to recruit for the project.
> There ain't no such thing as a free lunch. Firefox pays bills
Yes. And as a Firefox user/QA supporter from the m/b days I really
appreciate that and all the good it has brought to the project.
> Never mind that we have XUL App #2 (Thunderbird) and it faces
> other challenges because *it's not the browser*. I'm not saying a
> thick mail client should not be supported by the platform. I am
> saying it's bound to place or show, not win. That means it will
> not *necessarily* be included in the new repository.
What I really don't understand (maybe my lack of knowledge of VCSs
besides CVS is the reason) is, why the new repository must be
restricted to the core code and Firefox? What do we lose if we
add the other stuff like mail, mailnews, calendar, suite?
> Joost, Songbird, and Flock are not so hosted. Should they be, or
> our manifesto talk is all lies?
Don't you think that there is a huge difference between official
mozilla.org projects sustained by a real community and products
outside of mozilla.org, which are funded with VC money.
> But we're not going to make everyone happy. We're going to shrink
> and speed up our codebase
How will a restricted repository speed things up. You can already
restrict your cvs pull to directories which are needed by Firefox
and not pull the stuff in mail, mailnews, calendar or suite. Is that
not possible in Mercurial?
bre...@mozilla.org
> bren...@mozilla.org wrote on 28. Mar 2007:
> > There's strong feeling here, but not much that's true. If we didn't
> > care about the platform for other apps, we would not take bugfixes,
> > even late in the cycle or considered for inclusion on a maintenance
> > branch, for bugs that don't affect Firefox. But we do (see, e.g.,
> >https://bugzilla.mozilla.org/show_bug.cgi?id=362564or
> >https://bugzilla.mozilla.org/show_bug.cgi?id=176182).
>
> There's a difference between caring about the platform all of the
> time (and thereby adhering to the manifesto) or doing so only some
> of the time, which is my impression.
This flunks my "no free lunch", "scarcity is everywhere", "utopia is
not an option" test. No group or individual can "care" about
everything all of the time. Period, end of story!
There are trade-offs. One of the obvious ones where trademark,
marketing, and build/qa are invested, and we have the "products" vs.
"projects" solution in place. Even here, as noted, Firefox >>
Thunderbird for good, particular reasons.
> Just to be clear, I'm *not* calling you or other people from MoCo
> a huge bunch of liars, who are betraying the project. That wouldn't
> be true.
Ok, good to hear.
> But I see more and more indications that the project is
> moving from the "multitude of products with a premier app" point to
> the "One premier app and a bunch of other stuff which we tolerate
> unless it does not get in our way" point.
This is a "feelings" sort of judgment that it's fruitless to argue
about. I assert, and will be working hard to make true, that Mozilla 2
will *improve* the lives of all XUL apps compared to the unitary CVS
repository and the mess of embedding and other APIs, plus the
footprint, performance, and security problems of today.
> The first one is fine, the second one is not. This feels more and
> more like the days, when Netscape dominated the project and alienated
> more people than it helped to recruit for the project.
Let's try to get away from arguing about feelings. First, I think you
and I do not see eye to eye on scarcity being the fundamental fact of
economic life, including in Mozilla. Second, I think you want
something (hosting of calendar in the Moz2 repo from day 1) that is
unreasonable, and that may even be harmful to both calendar and
Mozilla 2.
Let's talk about these two things in concrete terms, if we can.
> > There ain't no such thing as a free lunch. Firefox pays bills
>
> Yes. And as a Firefox user/QA supporter from the m/b days I really
> appreciate that and all the good it has brought to the project.
Good to know too. I'm still not sure how your "caring about" above can
be reconciled with this understanding. If we cared less about the
suite -- and we did -- and that focus on the new standalone apps was
good for the project, then it's conceivable that the same focus and
better VCS tools can improve the lives of XUL app hackers, even if (or
*because*) their app sources are not hosted in the same repo as the
core code.
That Firefox will be co-hosted is a necessity, as I've written. If in
the very long run, Gerv's symmetric dream comes true (I'm frankly
skeptical), great. There's no _a priori_ reason that can't happen. All
of my skepticism is based on _a posteriori_ reasoning from experience
with Mozilla and other large systems that have "back end" and "front
end" code.
> > Never mind that we have XUL App #2 (Thunderbird) and it faces
> > other challenges because *it's not the browser*. I'm not saying a
> > thick mail client should not be supported by the platform. I am
> > saying it's bound to place or show, not win. That means it will
> > not *necessarily* be included in the new repository.
>
> What I really don't understand (maybe my lack of knowledge of VCSs
> besides CVS is the reason) is, why the new repository must be
> restricted to the core code and Firefox?
As I've already listed:
1. To keep it small and approachable.
2. To avoid entangling other apps with private or otherwise non-public
APIs.
3. To keep focused on Firefox *and* XULRunner, so the fast-moving
ecosystem built on both is better served, with priority to Firefox as
ever (see sayrer's posts too).
> What do we lose if we
> add the other stuff like mail, mailnews, calendar, suite?
No one working on them in the short run. Loss of focus if we have to
divide our time between rearchitecture that strengthens the APIs and
the core code, and that maintains more compatibility than Mozilla 2
could otherwise get away with. And the enganglements noted above.
We have significant problems today solving bugs bottom-up instead of
rearchitecting, while keeping backward compatibility at the API
layers. For Mozilla 2, this means we can break compatibility. If we
only have to worry about Firefox and XULRunner, then we may break some
semi-public or private API that Thunderbird uses, and it can "port" to
a better API we provide, later. Or it can join the party and add that
better API.
We do not do anyone, including Thunderbird (just to pick on it; could
be calendar stuff too) by serving multiple masters and "caring" about
too much. We need focus on Firefox and XULRunner, with other apps
joining the party at the XULRunner API negotiation layer, some time
after our initial work is well under way.
> > Joost, Songbird, and Flock are not so hosted. Should they be, or
> > our manifesto talk is all lies?
>
> Don't you think that there is a huge difference between official
> mozilla.org projects sustained by a real community and products
> outside of mozilla.org, which are funded with VC money.
What's this non-sequitur about? I explicitly cited their funding
status in the next sentence, which you do not cite. If your point is
that we should care more in practical ways about the non-funded XUL
apps, in ways that disrupt Mozilla 2's Firefox and XULRunner focus,
then I can't agree. We should not care more about any XUL app, funded
or not. They should all bring technical arguments to bear in favor of
API additions or changes, and their hackers should contribute patches.
It should not matter that "Sunbird's volunteer crew needs this API" or
"Joost needs this API" or "Simon needs this API". What should matter
is the API's form and fit, its security properties, the cost and
degree of its implementation(s), what happens to the overwhelming
majority of API consumers if we leave it out, and other such
considerations that can be judged according to shared technical
values.
Even a minority API user cohort can have influence based on technical
arguing, for sure. But we are not going to play favorites for or
against commercial and volunteer groups or individuals. We need to
continue to uphold a shared technical vision and values, with common
vocabulary and good reputation-system support, or we are doomed.
> > But we're not going to make everyone happy. We're going to shrink
> > and speed up our codebase
>
> How will a restricted repository speed things up. You can already
> restrict your cvs pull to directories which are needed by Firefox
> and not pull the stuff in mail, mailnews, calendar or suite. Is that
> not possible in Mercurial?
It's possible with Hg actually, but not with all such systems. So the
reasons I gave above for focus, entanglement-proofing, and
approachability are the reasons, not any particular VCS limitation. If
adding another XUL app to the Mozilla 2 repo is the right thing, we
can do it. But we won't at the start, just to have unowned in the
Mozilla 2 repo, auto-merged versions of those apps' sources.
/be
bre...@mozilla.org
that. Corrections below.
On Mar 28, 3:21 pm, "bren...@mozilla.org" <bren...@mozilla.org> wrote:
> There are trade-offs. One of the obvious ones where trademark,
"is" between "ones" and "where".
> marketing, and build/qa are invested, and we have the "products" vs.
> "projects" solution in place. Even here, as noted, Firefox >>
> Thunderbird for good, particular reasons.
[snip]
> We do not do anyone, including Thunderbird (just to pick on it; could
> be calendar stuff too) by serving multiple masters and "caring" about
Either s/We do not do/We do not help/ or (what I meant to write) "We
do not do anyone ... any favors by ...."
/be
Christian Biesinger
> Here is the minimal list of files and directories, including their
> subdirectories in the case of directories, from under
> cvs.mozilla.org's mozilla top-level directory, that I propose we
> migrate into the Mozilla 2 initial repository:
Will you import the entire modules/, or just what is also part of a
normal checkout?
Are you intentionally leaving out configure? (I wouldn't mind that)
bre...@mozilla.org
> bren...@mozilla.org wrote:
> > Here is the minimal list of files and directories, including their
> > subdirectories in the case of directories, from under
> > cvs.mozilla.org's mozilla top-level directory, that I propose we
> > migrate into the Mozilla 2 initial repository:
>
> Will you import the entire modules/, or just what is also part of a
> normal checkout?
Normal checkout, I think. Benjamin will do the deed, so I defer to
him.
> Are you intentionally leaving out configure? (I wouldn't mind that)
This is another one for Benjamin, but if we need it committed today
(and we do), then let's not hold up the Moz2 initial repo just to
polish this tiny bump to be a bit smoother.
/be
Christian Biesinger
> Firefox is not "just another XUL app". Mozilla would do a disservice
> to everyone in its community, not just "end users", if it pretended
> otherwise. Firefox and XULRunner/Gecko are the big lever we have to
> advance the web. And with the right fulcrum, we may be able to move
> mountains. We cannot treat all XUL apps equally in practice, even in
> an ideal world. Practically speaking, we are willing to couple Firefox
> to the back end, as it is today, via unfrozen APIs.
C'mon, Firefox does not need to limit itself to frozen APIs just because
it lives in a different repository.
bre...@mozilla.org
I'm not saying that. I'm arguing that we can make a "backroom deal"
for Firefox that we do not support for anyone else, that does not show
up in the DLL exports. Of course, Songbird or whomever could
understand how that deal works, hack the code they pull or import, and
use the same deal. It's all user-land software, no kernel-controlled
hardware MMU to enforce integrity properties. But with a new
repository, I'm more confident we could say "no" to "you must not
break my illicit use of your backroom deal API" demands.
/be
Christian Biesinger
> This is another one for Benjamin, but if we need it committed today
> (and we do), then let's not hold up the Moz2 initial repo just to
> polish this tiny bump to be a bit smoother.
Well, "need"... Even today, we could say "developers need to have
autoconf 2.13 installed", and have client.mk run that before running
configure. Few projects have generated files like that checked in.
I suppose the main issue here would be Windows, but we could include
autoconf 2.13 in MozillaBuild.
Christian Biesinger
> On Mar 28, 4:52 pm, Christian Biesinger <cbiesin...@web.de> wrote:
>> C'mon, Firefox does not need to limit itself to frozen APIs just because
>> it lives in a different repository.
>
> I'm not saying that. I'm arguing that we can make a "backroom deal"
> for Firefox that we do not support for anyone else, that does not show
> up in the DLL exports.
Perhaps you could clarify, when you say "unfrozen API", what do you
mean? For me, it mainly means unfrozen interfaces (IDL).
It seems like you mean the unfrozen C++ symbols, basically the stuff we
currently export from xpcom_core, including the internal string API?
bre...@mozilla.org
Here I am not up to date with Benjamin's work, but last I checked, it
was possible (easy on Windows, hard with the GCC toolchain but
possible) to hide all symbols except those that come from specially
decorated declarations (whether or not those C++ declarations came
from IDL primary sources). We definitely want to hide symbols in
libXUL (whatever-its-called) that are needed only "inside" the back
room (where the deal happens).
Again this is not hack-proof, and I don't want to make too much of it.
When I was writing about entanglements between app front ends and back
end code, I was not talking about intentional dependencies so much.
Those can be good, and solid APIs should be negotiated to serve all
use-cases that pass muster with the relevant owners and high-
reputation onlookers.
I was more concerned with unintended entanglement and requirement
overload. Having separate repositories is not an iron-clad guarantee
against such entanglement, but it mitigates the problem.
/be
Benjamin Smedberg
configure-2.13 is already in mozillabuild. However, there are plenty of
linux distros that do not come with it by default (requires a special
package), and I don't want to spend the time trying to get the generated
file into release tarballs that isn't in CVS. So for the moment, I will
import configure.
--BDS
Robert Kaiser
> It's silly to say "people will just use CVS because it's too hard to
> use two VCSes" given this. If you believe we will fail at Mozilla 2,
> say so. If you think there's something other than CVS that will favor
> too many people in the community sticking with cvs.mozilla.org in
> perpetuity, I'd like to hear what that something else might be.
This is completely NOT a case of which VCS we're using for Mozilla2, all
I'm talking about there is what code is in there. Needing to puzll from
4-5 repositories for just being able to build SeaMonkey sounds horrible
to me, no matter if they are CVS, hg, bzr, git or whatever.
My real problem is that I think for many people working on non-Firefox
apps it will be a lot harder to work with Mozilla2 as they need to set
up multiple (at least 2, if not more) repositories to pull from just to
get a current trunk build.
And they need to set up even more repositories if they want to just help
some other related project with some code.
Rather than doing that, they will probably stay with the monolithic CVS
tree instead of moving to a more modern VCS and not help other projects
within the community, as all that gets just annoyingly difficult. That's
what I fear. And that's nothing to do with the monolithic current repo
being CVS and the splitted ones being something else, actually. It's
just about the splitting of the mozilla.org tree that you're arbitrarily
introducing here.
Robert Kaiser
Robert Kaiser
> This is a good point too. I suspect many folks -- not all -- are
> laboring under the limitations, assumptions, and working culture of
> the CVS single master repository model.
Actually, I see more enabling of freedom and collaboration in that model
than I see any limitations. YMMV, though, I guess.
Robert kaiser
Robert Sayre
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
Boris Zbarsky
> However, I have two problems with the way you've characterized the
> interaction of the projects. The first objection is that JS, Gecko, and
> Firefox/Toolkit don't/won't depend on Seamonkey.
In practice, this is false. At the moment I pull (and build) Firefox,
XULRunner, Thunderbird, Seamonkey, and calendar just because I've made changes
in the past to core code that broke (as in "tree is red") some subset of those
because they were using C++ APIs that I changed. So unless you're suggesting
that someone who changes core APIs is not responsible for updating existing
consumers, I'm not sure how you envision this working.
Until we get to that holy grail of apps only using frozen core APIs, of course. ;)
That said, I agree that having to maintain all those apps for every single
(possibly experimental) API change in the mozilla2 tree is not something we want
to be doing. So I think the plan of just doing the initial stuff with Firefox,
then making sure all the changes work correctly with all apps later once we're
happy with it is the right thing in the short term. Long-term, we should think
about how we want to handle this.
-Boris
bre...@mozilla.org
> This is completely NOT a case of which VCS we're using for Mozilla2, all
> I'm talking about there is what code is in there. Needing to puzll from
> 4-5 repositories for just being able to build SeaMonkey sounds horrible
Why 4-5? The number should be <= 2 unless you add unstated
requirements that are not being proposed.
/be
Robert Kaiser
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
Robert Kaiser
> 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
>> 4-5 repositories for just being able to build SeaMonkey sounds horrible
>
> Why 4-5? The number should be <= 2 unless you add unstated
> requirements that are not being proposed.
I based this on the assumption that XULRunner, SeaMonkey-specific code,
shared mailnews code, venkman, Lightning, Chatzilla, might all live in
Robert Kaiser
> Robert Kaiser wrote:
>> bre...@mozilla.org schrieb:
>>> This is a good point too. I suspect many folks -- not all -- are
>>> laboring under the limitations, assumptions, and working culture of
>>> the CVS single master repository model.
>>
>> Actually, I see more enabling of freedom and collaboration in that
>> model than I see any limitations. YMMV, though, I guess.
>
> I do not see any "enabling of freedom" on CVS's part, whatever that
> might be. You'll have to be more specific.
As I said elsewhere, this is not CVS vs. other VCSes, but monolithic vs.
split trees, but I think you based your argument on that anyways.
I meant the freedom to easily help other projects with a fast patch,
include works from others in your app, etc. - which is quite easy if you
just need to pull an additional dir from the same repo.
> The second is objection is
> the unspoken assumption that developers working on Firefox will retreat
> to a cliquish single repository. That will not be the case, and the
> findability hazard will in fact be greater for Firefox and Gecko
> hackers, because work from Graydon, Taras, etc. is likely to result in a
> lot of code moving in many directions between many repositories.
OK, that's private vs. "the official" repositories, which will
frequently merge patchsets, I guess, and that's just how a decentralized
VCS works. Good.
Pulling non-official-trunk code for at-the-edge development of other
apps harms collaboration on the main code and fast finding of problems
on main core development source. So if the model is expected to be that
e.g. SeaMonkey has a copy of trees of all included code just in its
"official" working repository and merges that from time to time, you'll
come to the situation where SeaMonkey, Firefox, Thunderbird, Sunbird,
etc. rarely work with any similar copy of XULRunner and someone (like
me) who's currently used to pull and build all of them daily to test
some of his code with other apps just will start to ignore anything but
the main app he's working on. Which harms all our projects, IMHO.
But I guess the pull once, build multiple apps approach is just
something the decisionmakers here don't care about much.
> Your other message vastly overstates the coordination cost of separate
> repositories, imho. That is what these tools are designed to do.
I guess that depends on how you deal with that. If it means pulling the
"trunk" (or whatever we'll call it there) from several different
repositories just to build your app, it might get difficult. If the
development model is what I described above, I see those problem I
described there arising.
Robert Kaiser
Robert Kaiser
> Robert Sayre wrote:
>> However, I have two problems with the way you've characterized the
>> interaction of the projects. The first objection is that JS, Gecko,
>> and Firefox/Toolkit don't/won't depend on Seamonkey.
>
> In practice, this is false. At the moment I pull (and build) Firefox,
> XULRunner, Thunderbird, Seamonkey, and calendar just because I've made
> changes in the past to core code that broke (as in "tree is red") some
> subset of those because they were using C++ APIs that I changed. So
> unless you're suggesting that someone who changes core APIs is not
> responsible for updating existing consumers, I'm not sure how you
> envision this working.
From what I see in this discussion, the target is that other apps can
happily be broken because they live elsewhere and don't merge current
dev source into their base code until release time nears. And then, when
a XULRunner beta (or even final) has been done, they'll file all kind of
bugs about incompatibilities of APIs with non-FF apps that haven't been
tested when the APIs where invented because everyone else than FF lived
at a different codebase.
If the APIs can still be fixed at that point, I guess everything's fine,
else they'll just ship their modified XULRunner versions with their
apps, I guess...
Robert Kaiser
Benjamin Smedberg
> I guess that depends on how you deal with that. If it means pulling the
> "trunk" (or whatever we'll call it there) from several different
> repositories just to build your app, it might get difficult. If the
Why is that difficult? We will certainly have a client.mk-like solution to
pull the repositories together (just as we pull l10n/ and mozilla/ together
today). We are actively working on a non-monolithic configure system so that
you can build arbitrary apps on top of the core without hacking the main
configure scripts.
I don't see any need for SeaMonkey (for example) to maintain its own version
of the gecko core tree. Just use the standard one. Other more complex apps
such as Joost would use their own version, because they have hacked the
core. But the distributed VCS makes it much easier for them to track the
main tree and contribute changesets back.
--BDS
Benjamin Smedberg
> From what I see in this discussion, the target is that other apps can
> happily be broken because they live elsewhere and don't merge current
> dev source into their base code until release time nears. And then, when
> a XULRunner beta (or even final) has been done, they'll file all kind of
> bugs about incompatibilities of APIs with non-FF apps that haven't been
> tested when the APIs where invented because everyone else than FF lived
> at a different codebase.
It *is* the goal that core+firefox development can happen rapidly, and that
it's ok to break other apps along the way. The opportunity and resources we
have as a project should be focused on that combination, and we cannot
afford the coordination costs to keep everything (tbird, camino, etc)
unbroken all the time.
It is absolutely *not* the goal for each project to have their own fork of
the core repository, and it's silly or disingenious to state that it is.
The other projects have various ways they can coordinate:
1) they can pull and build on the trunk xulrunner and fix bustages as they come.
2) they can pull from known-good revisions of the xulrunner repo and upgrade
as appropriate (nightly/weekly)
3) they can wait for API stability points (e.g. feature-complete betas) and
upgrade "late".
Different projects may use different strategies, depending on the resources
at their disposal. Obviously using the trunk xulrunner (constantly or
frequently) will reduce the opportunities for major regressions.
--BDS
Robert Kaiser
> 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
Robert Kaiser
> 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
Boris Zbarsky
> 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
Benjamin Smedberg
> 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
Boris Zbarsky
> 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
Gijs Kruitbosch
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
bre...@mozilla.org
> 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
Boris Zbarsky
> But new enough, and as you note independent of the source hosting, to
> bring up in a new thread?
imo, yes.
-Boris
Alex Vincent
> 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
Benjamin Smedberg
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
Benjamin Smedberg
James Ross
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 <sil...@warwickcompsoc.co.uk>
ChatZilla and Venkman Developer
Simon Paquet
>> 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 <18ednY5TPuAqXpbb...@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
Benjamin Smedberg
> 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
bre...@mozilla.org
> 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
Mike Shaver
> 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
Boris Zbarsky
> 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
Neil
> 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.
Benjamin Smedberg
> 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
Benjamin Smedberg
> 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
Boris Zbarsky
> 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
Boris Zbarsky
> 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
Benjamin Smedberg
> 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
Boris Zbarsky
> 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
> 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
Benjamin Smedberg
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
Boris Zbarsky
> 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
Axel Hecht
> 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
Robert Kaiser
> 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
Benjamin Smedberg
> 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
Simon Paquet
So MoCo is essentially abandoning its second product (Thunderbird) in
favor of Firefox?
Interesting...
bre...@mozilla.org
> 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
bre...@mozilla.org
> 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
Benjamin Smedberg
> 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
bre...@mozilla.org
> 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
Axel Hecht
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
Robert Kaiser
> 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
Boris Zbarsky
> 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
Boris Zbarsky
> 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
bre...@mozilla.org
> 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
Karsten Düsterloh
> 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. :)
Brendan Eich
> bre...@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
Robert Kaiser
> 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 Sayre
> 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.
>
> 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
Karsten Düsterloh
> 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.
Robert Kaiser
> 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
Benjamin Smedberg
> 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
Axel Hecht
> 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
Boris Zbarsky
> 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
Robert Kaiser
> 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
Dan Mosedale
> 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
Benjamin Smedberg
>> 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
bre...@mozilla.org
> > 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