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 res
