Mercurial Repository Structure
Benjamin Smedberg
of l10n files:
PROPOSAL:
hg.mozilla.org/mozilla-central-l10n/af
hg.mozilla.org/mozilla-central-l10n/ar
hg.mozilla.org/mozilla-central-l10n/...
These repositories contain the localized files for the mozilla-central
repository (the core platform/XULRunner/Firefox).
hg.mozilla.org/comm-central-l10n/af
hg.mozilla.org/comm-central-l10n/ar
hg.mozilla.org/comm-central-l10n/...
These repositories contain the localized files for the comm-central
repository (thunderbird/seamonkey/calendar).
Other projects such as Fennec (mobile) which need to be localized in the
future would also have separate l10n repositories:
hg.mozilla.org/mobile-browser-l10n/af...
RATIONALE:
Multiple locales should not share repositories:
* A shared repository would be pretty large, and every localizer would have
to download all the other locales in order to work on his own
* Every time a change was made in another locale, a locale maintainer would
have to update/merge their local copy, which can be confusing
Different projects (mozilla-central/comm-central) should not share repositories:
* The projects are logically separate, and will have branch/tag/release
points which are out of sync. Combining sources means that maintaining
branches and tags is quite complicated.
* With separate repostories, it is perfectly clear which sources are used to
build which products. This is very important for distributors and embedders,
and is one of the reasons we split mozilla-central and comm-central in the
first place. It also makes end-game driving much easier, since it is likely
that mozilla-central and comm-central will have separate drivers and be
under driver control at different times.
* It makes it much easier to add new or experimental projects such as
mobile-browser.
* It makes it easier for different localization teams to work on firefox and
thunderbird without requiring repository merging.
OPEN ISSUES:
Should we take a flat import of CVS into Mercurial, or should we attempt to
import history?
* A flat import is trivial, and I can do it today, if desired
* Axel performed a test import of de with history. It's possible to do, but
has some issues with importing branches and importing sources we don't
necessarily want to import.
Thoughts? I'm not clear on what value past history actually is to localizers.
--BDS
Robert Kaiser
> Different projects (mozilla-central/comm-central) should not share
> repositories:
>
> * The projects are logically separate, and will have branch/tag/release
> points which are out of sync. Combining sources means that maintaining
> branches and tags is quite complicated.
Buit the localizations are not logically separate in almost all cases.
> * With separate repostories, it is perfectly clear which sources are
> used to build which products.
But it's not clear, as editor/ui (and probably its locales) lives in
mozilla-central but is only needed by SeaMonkey and Thunderbird. Same
goes for some parts of security/manager. So, for localizers, we don't
have clarity there.
> * It makes it much easier to add new or experimental projects such as
> mobile-browser.
Not so sure about that, but you may have that point.
> * It makes it easier for different localization teams to work on firefox
> and thunderbird without requiring repository merging.
I don't understand that argument. Thunderbird or SeaMonkey or Sunbird
(which also lives in comm-central in the future) teams can't work
independently of Firefox teams anyway because they share the
toolkit/platforms parts in any case.
What you completely miss here is that getting sources from different
parts of the application into different repositories only makes the work
harder for localizers, who probably do not understand a lot about source
management anyhow.
And I have no clue yet where you expect SeaMonkey to pull L10n for DOMi,
venkman, and ChatZilla, whose source will probably all live in their own
repositories.
That said, I'm 1) against splitting L10n for different source repos and
2) against having a separate toplevel dir for every L10n/source
combination and not a unified l10n/ subdir on hg.mozilla.org.
Robert Kaiser
Robert Kaiser
Benjamin Smedberg
> I don't understand that argument. Thunderbird or SeaMonkey or Sunbird
> (which also lives in comm-central in the future) teams can't work
> independently of Firefox teams anyway because they share the
> toolkit/platforms parts in any case.
When we get to the point where the apps are built on top of XULRunner, that
will not be the case.
--BDS
Benjamin Smedberg
> And I have no clue yet where you expect SeaMonkey to pull L10n for DOMi,
> venkman, and ChatZilla, whose source will probably all live in their own
> repositories.
Your main directory structure will be something like:
suitesrc/
suitesrc/suite/locales
suitesrc/mozilla
suitesrc/mozilla/toolkit/locales
Benjamin Smedberg
> And I have no clue yet where you expect SeaMonkey to pull L10n for DOMi,
> venkman, and ChatZilla, whose source will probably all live in their own
> repositories.
Urgh, sent too soon:
Your main directory structure will be something like:
suitesrc/
suitesrc/suite/locales
suitesrc/mozilla
suitesrc/mozilla/toolkit/locales
And the locales would be pulled into:
suitesrc/l10n/de (comm-central-l10n/de)
suitesrc/mozilla/l10n/de (mozilla-central-l10n/de)
You're currently pulling venkman into
suitesrc/mozilla/extensions/venkman
So its locales could be pulled to
suitesrc/mozilla/extensions/venkman/l10n
--BDS
Axel Hecht
I find this very confusing. Can we punt that off until we have said
xulrunner builds and localizers have a bit more experience with stuff?
Right now, I figure you're changing a whole lot of things at once, and I
find it hard to see the impact of it.
If a localizer would work on the sources of a build, that'd spread his
work items all over a full check out of mozilla-central? Without a hook
to branch? :-/
IMHO, we should be able to redirect the build to any directory for a
l10ntopsrcdir, and resolve relative paths relative to that. Pretty much
like we do on cvs.
If we had to modularize, we could do so, but I'd rather not do that
today and hold off on builds. If we at one point figure that we're in
need to get more modular, we can still do so.
Axel
Pavel Franc
> 2) against having a separate toplevel dir for every L10n/source
> combination and not a unified l10n/ subdir on hg.mozilla.org.
>
Personally I would prefer one repository per locale with respective
subdirectories.
RATIONALE:
* It is easier to handle one repository then handling repositories for
mozilla, communication, mobile, chatzilla, domi, whatever...
* Even if you do only localization of Thunderbird, you should have both
localization of browser, toolkit and suite to be consistent across
Mozilla applications.
* If you have multiple repositories per locale you have to have multiple
access rights which means more complications for localizers
Pavel
Czech Mozilla Team
Ricardo Palomares Martínez
> I would like to propose the following structure for Mercurial
> repositories of l10n files:
>
> PROPOSAL:
>
> Multiple locales should not share repositories:
>
OK for me.
> Different projects (mozilla-central/comm-central) should not share
> repositories:
>
> * The projects are logically separate, and will have branch/tag/release
> points which are out of sync. Combining sources means that maintaining
> branches and tags is quite complicated.
I currently work in a similar way with CVS (I check out a number of
directories for toolkit in a separate directory; another set of
directories for Thunderbird in another separate directory, and so on),
but I guess there is more with Mercurial than just doing a selective
check out. I must say than I don't currently use client scripts
available in Mozilla repository for L10n (and I'd like to go back to
standards with Hg).
So, *apparently*, I don't see too much trouble with this proposal, but
I won't be surprised to be missing something here.
> OPEN ISSUES:
>
> Should we take a flat import of CVS into Mercurial, or should we attempt
> to import history?
>
> * A flat import is trivial, and I can do it today, if desired
> * Axel performed a test import of de with history. It's possible to do,
> but has some issues with importing branches and importing sources we
> don't necessarily want to import.
>
> Thoughts? I'm not clear on what value past history actually is to
> localizers.
As long as I can query bonsai for CVS history, I hardly will do it
through CVS command line.
But I'd really really really like Mozilla (Axel, maybe?) to organize a
"intro session" on IRC with localizers so we can get a first "guided
tour" on hg, so we don't mess it right once we have our locales
imported. We will mess it sooner or later, that's for sure, but if we
can minimize it, it would be wonderful. :-)
Justin Wood (Callek)
What about mail/locales, calendar/locals?
shouldn't it be suitesrc/locales and suitesrc/mozilla/locales if we go
this route?
--
~Justin Wood (Callek)
Justin Wood (Callek)
Scratch those questions, just read his followup...
--
~Justin Wood (Callek)
Rimas Kudelis
checkout en-US files only or to add a localization of new product. With
stuff split into multiple trees, this would only get harder.
I think, a structure like this:
hg.mozilla.org/l10n-central/xx/toolkit
hg.mozilla.org/l10n-central/xx/browser
hg.mozilla.org/l10n-central/xx/mail
hg.mozilla.org/l10n-central/xx/etc
would make much more sense. This way multiple locales would not share
repositories, and the separation between projects would be clear enough.
Furthermore, as already noted, even while applications are different,
they are *usually* localized by same people or at least same teams
(they're supposed to coordinate translation terms and style, at least),
so there aren't many reasons to separate.
The only point that remains unclear for me in this situation is end-game
driving and branching/tagging/whatever_you_call_it_in_hg.
RQ
Axel Hecht
> Benjamin Smedberg escribió:
>> I would like to propose the following structure for Mercurial
>> repositories of l10n files:
>>
>> PROPOSAL:
>> RATIONALE:
>>
>> Multiple locales should not share repositories:
>>
>
>
> OK for me.
>
>
>> Different projects (mozilla-central/comm-central) should not share
>> repositories:
>>
>> * The projects are logically separate, and will have branch/tag/release
>> points which are out of sync. Combining sources means that maintaining
>> branches and tags is quite complicated.
>
>
> I currently work in a similar way with CVS (I check out a number of
> directories for toolkit in a separate directory; another set of
> directories for Thunderbird in another separate directory, and so on),
> but I guess there is more with Mercurial than just doing a selective
> check out. I must say than I don't currently use client scripts
> available in Mozilla repository for L10n (and I'd like to go back to
> standards with Hg).
>
> So, *apparently*, I don't see too much trouble with this proposal, but
> I won't be surprised to be missing something here.
As of now, hg doesn't support partial checkouts.
>> OPEN ISSUES:
>>
>> Should we take a flat import of CVS into Mercurial, or should we attempt
>> to import history?
>>
>> * A flat import is trivial, and I can do it today, if desired
>> * Axel performed a test import of de with history. It's possible to do,
>> but has some issues with importing branches and importing sources we
>> don't necessarily want to import.
>>
>> Thoughts? I'm not clear on what value past history actually is to
>> localizers.
>
>
> As long as I can query bonsai for CVS history, I hardly will do it
> through CVS command line.
>
> But I'd really really really like Mozilla (Axel, maybe?) to organize a
> "intro session" on IRC with localizers so we can get a first "guided
> tour" on hg, so we don't mess it right once we have our locales
> imported. We will mess it sooner or later, that's for sure, but if we
> can minimize it, it would be wonderful. :-)
In planning...
Axel
Marcelo Poli
> I'm all with Pavel and Axel. Even now it's complicated enough to
> checkout en-US files only or to add a localization of new product. With
> stuff split into multiple trees, this would only get harder.
>
> I think, a structure like this:
> hg.mozilla.org/l10n-central/xx/toolkit
> hg.mozilla.org/l10n-central/xx/browser
> hg.mozilla.org/l10n-central/xx/mail
> hg.mozilla.org/l10n-central/xx/etc
> would make much more sense. This way multiple locales would not share
> repositories, and the separation between projects would be clear enough.
>
> Furthermore, as already noted, even while applications are different,
> they are *usually* localized by same people or at least same teams
> (they're supposed to coordinate translation terms and style, at least),
> so there aren't many reasons to separate.
applications.
As today, I think that every language has a team that coordinate
translation. I agree that there's no need to separate.
文少华
And please put en-US into the l10n directory also( if possible ), which will
make things much easier.
BR.
Holy
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>