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:
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).
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:
> <snip> > xpfe > <snip>
> See http://wiki.mozilla.org/Mozilla2 for more. The initial repository > will be a Mercurial one, but don't panic. We need to get to work on > Mozilla 2 concurrently with 1.9, and we can't wait for the perfect > repository solution to emerge. We'll start with hg, and reconsider bzr > if it speeds up enough. See preed's blog for why we can't use git or > other contenders and wannabes.
> Also do not panic about the above list leaving out mail, mailnews, > composer, calendar, camino, etc. Mozilla 2 needs focus and the > repository can grow. Or, with better VCSes such as hg, we can have > several repositories. With better embedding APIs we won't want to > tightly couple source of a given XUL app to source of a given Gecko > back end file. But we will want to keep Firefox and XULRunner building > at all times. So the above list does include those two.
> Comments welcome, but we are likely to create this soon. Useful > comments would be "don't forget xyzzy or you can't build foopy", not > "why aren't you importing electricalfire" or the like.
> Thanks to Benjamin for help getting this list right (jst and pav too).
> /be
It's my understanding that xpfe is currently only used by the Suite, and they're moving away from it. Could someone explain why it is in this list, then? (My apologies for any ignorance demonstrated - I suppose I'm just curious)
Gijs Kruitbosch wrote: > It's my understanding that xpfe is currently only used by the Suite, and > they're moving away from it. Could someone explain why it is in this > list, then? (My apologies for any ignorance demonstrated - I suppose I'm > just curious)
> -- Gijs
I believe Firefox still depends on some code in xpfe, including xpfe/appshell.
On Mar 27, 11:37 pm, Gijs Kruitbosch <gijskruitbo...@gmail.com> wrote:
> It's my understanding that xpfe is currently only used by the Suite, and > they're moving away from it. Could someone explain why it is in this > list, then? (My apologies for any ignorance demonstrated - I suppose I'm > just curious)
(I replied via email to Gijs already, but for the record:)
xpfe is pulled and built when building Firefox, at least parts of it are. We don't propose to "fix" this before starting the Mozilla 2 migration.
BTW, in case it's not clear from the wiki docs and my origina Mozilla 2 blog, we will of course use the new repository's better branching and merging to automate merges from the 1.9 CVS trunk into the Hg repo, probably nightly to a copy of the trunk. From that, we'll maintain a branch that periodically, based on known-good 1.9 status, merges 1.9 and Mozilla 2. As noted in my blog, we anticipate many experimental branches (for Tamarin work, Oink/Elsa-based refactoring, etc.) and related integration branches feeding back into the main Mozilla 2 branch.
In the course of the next few months, we should also find it easier in Hg to rename and remove things, including xpfe if we can (sun-java too). So Gijs' point is well taken.
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.
> 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.
> 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.
Gijs Kruitbosch wrote: > It's my understanding that xpfe is currently only used by the Suite, and > they're moving away from it. Could someone explain why it is in this > list, then? (My apologies for any ignorance demonstrated - I suppose I'm > just curious)
xpfe/ is a wasteland of code built by various apps. Some of it is in the platform (xpfe/appshell), some of it is inconveniently shared between firefox and seamonkey (xpfe/components/...). We are gradually working towards moving everything out of xpfe/ to an appropriate module, but for the time being it is needed.
> 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.
> 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 wrote: > Well, this means that people working on anything else than Firefox will > probably just not care about that Mozilla2 repo as they can't build > their stuff with/from it. That may be intended, but it creates a major > split within the Mozilla dev community (the privileged who can use > Mozilla2, and the dumb rest that is more or less closed out from it and > whose wishes/bugs/problems won't be looked at a lot there). I'm not sure > this is a good thing to do.
This is a natural continuation of the plans to separate the "core" from the apps built on top of it. Firefox has a special place here because it is the primary app used to test the core, and its primary driver.
All of our apps are going to be built on the xulrunner core in the moz2 timeframe, and the repository structure is just a natural extension of that architecture.
Benjamin Smedberg wrote: > This is a natural continuation of the plans to separate the "core" from the > apps built on top of it. Firefox has a special place here because it is the > primary app used to test the core, and its primary driver.
> All of our apps are going to be built on the xulrunner core in the moz2 > timeframe, and the repository structure is just a natural extension of that > architecture.
If the idea is that every XULRunner app apart from Firefox is built by pulling from 2 (or more) repositories - the core one and the app-specific one - and combining the result, why not apply the same logic to Firefox? It would mean that whatever magic is necessary to perform such a combination is guaranteed to keep working. And it would guarantee a clean interface between what was platform and what was not.
> > 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.
On Mar 28, 9:51 am, Gervase Markham <g...@mozilla.org> wrote:
> Benjamin Smedberg wrote: > > This is a natural continuation of the plans to separate the "core" from the > > apps built on top of it. Firefox has a special place here because it is the > > primary app used to test the core, and its primary driver.
> > All of our apps are going to be built on the xulrunner core in the moz2 > > timeframe, and the repository structure is just a natural extension of that > > architecture.
> If the idea is that every XULRunner app apart from Firefox is built by > pulling from 2 (or more) repositories - the core one and the > app-specific one - and combining the result, why not apply the same > logic to Firefox?
Because that's a lot of work we don't need to do right now, and can't afford to do right now. Mozilla 2 is already under way and it needs a repository. We need working Firefox and XULRunner built on it.
> It would mean that whatever magic is necessary to > perform such a combination is guaranteed to keep working. And it would > guarantee a clean interface between what was platform and what was not.
There's no point in perfecting the separation of any given modules before we start the Mozilla 2 repository. Nor must we do all that work in the 1.9 time frame -- most of it fits in Mozilla 2 much better. We are not going to spend all our time first cleaning up widget or gfx, or removing nss and nsprpub to their own repos, etc. etc. Shaver keeps attributing Voltaire's "best is the enemy of the good" to me, and what did Voltaire know? But it fits here.
On Mar 28, 9:16 am, Robert Kaiser <k...@kairo.at> wrote:
> I see no recent comment on that, and given that reportedly the only real > argument against git is/was that almost half a year ago there was no > well-performing win32 port. This reportedly has changed, so despite some > people telling "git is no option" without bringing forward any current > argument, I think it should be re-evaluated as a third possible choice. > From what I hear, it probably has the most vibrant dev community of all > those choices and works well with a few quite big (in code and community > size) projects - and I tend to think that's something that has value for > Mozilla as well.
Got a link to pages documenting this git windows work? jst uses git on cvs today, he keeps up, he's a fan. It's not as if we have it in for git.
> Well, this means that people working on anything else than Firefox will > probably just not care about that Mozilla2 repo as they can't build > their stuff with/from it. That may be intended, but it creates a major > split within the Mozilla dev community (the privileged who can use > Mozilla2, and the dumb rest that is more or less closed out from it and > whose wishes/bugs/problems won't be looked at a lot there).
Nice false dilemma. But since we will give all committers access to the new repo, and merge trunk changes into Mozilla 2, and keep API compatibility where we want it (and in all cases, initially), it's simply not true that anyone is locked out.
Having to host an app elsewhere from the core back end has its pluses and minuses. It's already being done by the Flocks, Joosts, and Songbirds of the world. It was done by chimera (camino) initially. Tinderbox/buildbot coverage is independent of source hosting.
> I'm not sure > this is a good thing to do.
It's a trade-off:
Pro: focus on Mozilla 2 APIs for Firefox and XULRunner; smaller pull; more approachable repository (contrast to webkit).
Con: two repositories for other apps; feelings of a division among apps and people.
If we can use features of the new VCS to host other apps in the new repo but not obtrusively, we may consider using such features. But now is not the time to worry about this, before we've committed any of the automated refactoring patches taras is generating, or done any of the other more bottom-up/back-to-front work for Moz2.
> In my eyes, reducing the amount of code managed by the repo just tells > that the new VCS is not as capable as CVS of managing a huge codebase > like the one we have.
On Mar 28, 10:31 am, "bren...@mozilla.org" <bren...@mozilla.org> wrote:
> It's a trade-off:
> Pro: focus on Mozilla 2 APIs for Firefox and XULRunner; smaller pull; > more approachable repository (contrast to webkit).
As I noted in an earlier mail, it also reduces odds of unwanted coupling to private or other APis.
> Con: two repositories for other apps; feelings of a division among > apps and people.
Trade-off duality says: it makes it hard for other apps to use secret APIs they might want to use; it raises the odds of Firefox or XULRunner using such APIs (but that's arguably ok if other apps are XULRunner based and do not need such APIs).
> 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.
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.
> 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.
On Mar 28, 11:42 am, Simon Paquet <web...@babylonsounds.com> wrote:
> I just wish that they would openly say so, and not try to tell people > otherwise or blind people's eyes with stuff like the manifesto, which > MoCo obviously has no intention to adhere to.
Careful with the accusations of dishonesty or at least hypocrisy.
There 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).
> 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?
> > 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?
On Mar 28, 10:24 am, "bren...@mozilla.org" <bren...@mozilla.org> wrote:
> On Mar 28, 9:51 am, Gervase Markham <g...@mozilla.org> wrote: > > Benjamin Smedberg wrote: > > > All of our apps are going to be built on the xulrunner core in the moz2 > > > timeframe, and the repository structure is just a natural extension of that > > > architecture.
> > If the idea is that every XULRunner app apart from Firefox is built by > > pulling from 2 (or more) repositories - the core one and the > > app-specific one - and combining the result, why not apply the same > > logic to Firefox?
> Because that's a lot of work we don't need to do right now, and can't > afford to do right now. Mozilla 2 is already under way and it needs a > repository. We need working Firefox and XULRunner built on it.
In addition to the expediency argument, it's clear to me that a dream- world where the core XULRunner and Gecko code is in one repository, and Firefox is in another, symmetric with respect to other XUL apps, is just that: a dream world. I'd like to pick on Gerv's "why not apply the same logic" question a bit more (he can take it ;-).
Firefox is not "just another XUL app". Mozilla would do a disservice to everyone in its community, not just "end users", if it pretended otherwise. Firefox and XULRunner/Gecko are the big lever we have to advance the web. And with the right fulcrum, we may be able to move mountains. We cannot treat all XUL apps equally in practice, even in an ideal world. Practically speaking, we are willing to couple Firefox to the back end, as it is today, via unfrozen APIs.
We aspire to freeze all such APIs. But if we don't succeed by any given release (e.g., Firefox 4 on top of Mozilla 2), then we will couple front to back end within the new repository.
On Mar 28, 11:53 am, Robert Kaiser <k...@kairo.at> wrote: [git news snipped]
We'll need to evaluate the situation, but we need to move now. We've already delayed enough evaluating bzr. All these VCSes are moving targets, and we can't keep trying the latest unmerged experiment or port or we will never pick one and move. Again, we can switch later, especially once we have moved to a changeset based system. It's clearly wrong to say "we've picked the right system for the next ten years". But (see below) it's also wrong to stick with CVS for Mozilla 2.
> > Nice false dilemma. But since we will give all committers access to > > the new repo, and merge trunk changes into Mozilla 2, and keep API > > compatibility where we want it (and in all cases, initially), it's > > simply not true that anyone is locked out.
> Well, locked out might be the wrong term.
It is.
> I just quite sure that many > people will just not care about the Mozilla2 repo if working with the > old CVS is not only what they're used to but also a lot easier, not > needing to set up multiple repositories etc.
Well, now you are changing your argument. If some users don't want anything but CVS, they will indeed be stuck. But the Mozilla project's future after 1.9 is Mozilla 2. cvs.mozilla.org will live forever, but the main line of development, the place where sustained security bug- fixing and rearchitecture, Tamarin integration, performance work, embedding API that we can support, etc., will be the new repository.
It's silly to say "people will just use CVS because it's too hard to use two VCSes" given this. If you believe we will fail at Mozilla 2, say so. If you think there's something other than CVS that will favor too many people in the community sticking with cvs.mozilla.org in perpetuity, I'd like to hear what that something else might be.
> This in turn will likely keep them away from Mozilla2 work, splitting > the project and removing them from the edge of development (even though > not directly _locking_ them away from it).
Your argument now is that we can never move from CVS to a new VCS because it would split the community. But that is false, given all the folks already using new VCSes layered on top-of-trunk pulls from CVS. And it ignores all the wins of the new VCSes, some of which are necessary for Mozilla 2.
>> 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 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?
