[ANNOUNCEMENT] 1.9.1 repositories open, Firefox 3.1 and all of comm-central moved
Axel Hecht
the 1.9.1 repositories are open for business.
Your 1.9.1 repository is at
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/ab-CD/.
All current applications work on the 1.9.1 repositories, aka
Firefox 3.1
Thunderbird 3
SeaMonkey 2
The only projects so far that continue on l10n-central are
Firefox 3.2
(Fennec, coming up, still no builds there)
If you wish to ignore Firefox 3.2 (and Fennec), here's what I recommend
doing:
Update your en-US repo to point to 1.9.1.
For folks only working on Firefox, edit the .hg/hgrc file in your
mozilla-central clone to point to
http://hg.mozilla.org/releases/mozilla-1.9.1/
instead of mozilla-central.
comm-central is where it used to be, and client.py will migrate your
mozilla-central clone in there to a 1.9.1 clone.
Update your l10n repository to be a 1.9.1 repo:
Edit .hg/hgrc to look somewhat like this:
[paths]
default = http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/af/
default-push = ssh://hg.mozilla.org/releases/l10n-mozilla-1.9.1/af/
central = ssh://hg.mozilla.org/l10n-central/af/
What this does is that it sets you up with a repo that by default pulls
and pushes from the 1.9.1 repo, and that can easily push to central.
Now hg pull, hg update, to get the latest 1.9.1 status, and do you edits
as you would normally do.
Occasionally, you can now do a
hg push central
where central is the alias we defined above. This will update the
l10n-central repo with your work you did for 1.9.1, and bootstrap your
repo there for Firefox 3.2 and Fennec work.
This works as long as there are no other landings on the l10n-central
repo. Once that happens, you'll need to spend some more work. That
should be easier with hg 1.1, due any time now. I'll go into detail
about that then. For now and for those teams that already landed patches
in 1.9.1, you should just apply the patches from one repo in the other.
Shouldn't make things any worse than they already are.
I'll actively invite you to actually work on 3.2 rather soon, too. I'm
hoping to see the build system coming for that that we've promised for
some time, with nightly builds on an update channel, and that will be
good. And I'll invite you to work on Fennec. If we're lucky, you'll see
hg 1.1 support in TortoiseHG etc by then.
If you have questions, please ask in #l10n, or in the newsgroup. Don't
try to guess, it's easy to break things in the new land we're heading for.
Axel
Alexander Ihrig
> All current applications work on the 1.9.1 repositories, aka
>
> Firefox 3.1
> Thunderbird 3
> SeaMonkey 2
>
> The only projects so far that continue on l10n-central are
>
> Firefox 3.2
> (Fennec, coming up, still no builds there)
What about Sunbird/Lightning? I suspect that they (only) live in
l10n-central?
Regards
Alex Ihrig
Axel Hecht
All comm-central apps work against the 1.9.1 repositories, AFAIK.
Axel
Mark Banner
>> What about Sunbird/Lightning? I suspect that they (only) live in
>> l10n-central?
>
> All comm-central apps work against the 1.9.1 repositories, AFAIK.
Currently that is correct. At some stage in the future we will be
splitting into two (we'll do appropriate announcements at that time).
Standard8
Robert Kaiser
Yes, Firefox 3.1, Thunderbird 3.0, SeaMonkey 2.0, Sunbird/Lightning 1.0
are all coming off 1.9.1 and working off the 1.9.1 L10n repositories
now. Firefox 3.2 and in the future Fennec are the only ones currently
caring about l10n-central.
There will be a point where we branch the SeaMonkey/Thunderbird/calendar
source itself as well, and then we'll continue to stay with 1.9.1 for
the release seires mentioned above and use l10n-central for the next
upcoming release series, whatever versioning our products will use for
those (mostly undecided atm).
Robert Kaiser
Дамјан Георгиевски
>
> Edit .hg/hgrc to look somewhat like this:
>
> [paths]
> default = http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/af/
> default-push = ssh://hg.mozilla.org/releases/l10n-mozilla-1.9.1/af/
> central = ssh://hg.mozilla.org/l10n-central/af/
>
> What this does is that it sets you up with a repo that by default
> pulls and pushes from the 1.9.1 repo, and that can easily push to
> central.
>
> Now hg pull, hg update, to get the latest 1.9.1 status, and do you
> edits as you would normally do.
$ hg pull
pulling from http://hg.mozilla.org/releases/mozilla-1.9.1/mk/
searching for changes
abort: repository is unrelated
Mercurial Distributed SCM (version 1.0.2)
Python 2.6
(if it matters)
--
дамјан ( http://softver.org.mk/damjan/ )
In theory, there is no difference between theory and practice.
But, in practice, there is.
Carlos Simão
the one you entered is incorrect.
cheers
2008/12/3 Дамјан Георгиевски <gda...@gmail.com>:
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
Дамјан Георгиевски
I missed a l10n- there
--
дамјан ( http://softver.org.mk/damjan/ )
Real men don't use backups, they post their stuff on a public ftp server
and let the rest of the world make copies.
-- Linus Torvalds
Axel Hecht
>> Update your l10n repository to be a 1.9.1 repo:
>>
>> Edit .hg/hgrc to look somewhat like this:
>>
>> [paths]
>> default = http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/af/
>> default-push = ssh://hg.mozilla.org/releases/l10n-mozilla-1.9.1/af/
>> central = ssh://hg.mozilla.org/l10n-central/af/
>>
>> What this does is that it sets you up with a repo that by default
>> pulls and pushes from the 1.9.1 repo, and that can easily push to
>> central.
>>
>> Now hg pull, hg update, to get the latest 1.9.1 status, and do you
>> edits as you would normally do.
>
> $ hg pull
> pulling from http://hg.mozilla.org/releases/mozilla-1.9.1/mk/
> searching for changes
> abort: repository is unrelated
Pulling from http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/mk/
should be better. Note the missing "l10n-".
Axel
Ricardo Palomares Martínez
> Hi all,
>
> the 1.9.1 repositories are open for business.
>
> Your 1.9.1 repository is at
> http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/ab-CD/.
I must be doing something wrong, I think, because I can't get
Thunderbird 3.0 go green at:
http://l10n.mozilla.org/dashboard/?locale=es-ES
The report says that toolkit strings are missing, but the same strings
work for SeaMonkey 2.0 and Sunbird 1.0 [1]. Should I push to central,
just in case? Even if it works, is that correct (I understand it is not)?
[1]
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/es-ES/pushloghtml?changeset=ef5d1db5c0d8
TIA
Axel Hecht
Sorry, there were a few remaining problems with picking the right repos
yesterday, I forced a new build for es-ES and that's green now.
Axel
Ricardo Palomares Martínez
> Sorry, there were a few remaining problems with picking the right repos
> yesterday, I forced a new build for es-ES and that's green now.
Thank you for fixing it so promptly. :-)
Ricardo
Kristján Bjarni Guðmundsson
wrote:
Are you sure this is correct?
I have made my changes to Calendar in the l10n.mozilla-1.9.1
repository for my locale (is) but the dashboard still shows red for
sunbird10x.
It seems to me that Sunbird actually uses l10n-central and not
l10n-mozilla-1.9.1, can anybody confirm this?
- Kristján
Robert Kaiser
> Are you sure this is correct?
Yes.
> I have made my changes to Calendar in the l10n.mozilla-1.9.1
> repository for my locale (is) but the dashboard still shows red for
> sunbird10x.
It's possible that dashboard isn't correctly fixed yet.
> It seems to me that Sunbird actually uses l10n-central and not
> l10n-mozilla-1.9.1, can anybody confirm this?
Sunbird itself surely uses (or should use) the 1.9.1 repositories, as it
also uses the source code from the Mozilla 1.9.1 repository.
Robert Kaiser
"João Miguel Neves (EN)"
>> I have made my changes to Calendar in the l10n.mozilla-1.9.1
>> repository for my locale (is) but the dashboard still shows red for
>> sunbird10x.
>
> It's possible that dashboard isn't correctly fixed yet.
>
l10n-central.
Best regards,
João Miguel Neves
--
Intraneia
http://www.intraneia.com/
Free Software Support
Software/Site Localization
Software Development
At your service
João Miguel Neves
> Robert Kaiser escreveu:
>
>>> I have made my changes to Calendar in the l10n.mozilla-1.9.1
>>> repository for my locale (is) but the dashboard still shows red for
>>> sunbird10x.
>>>
>> It's possible that dashboard isn't correctly fixed yet.
>>
>>
> l10n-central
Best regards,
João Miguel Neves
--
Intraneia
http://www.intraneia.com/
Suporte a Software Livre
Tradução/Localização de software e sítios web
Desenvolvimento de software
Ao seu serviço...
Robert Kaiser
> João Miguel Neves (EN) escreveu:
>> l10n-central
> And the same applies to seamonkey.
I can confirm that it doesn't apply to SeaMonkey. The sea20x tree on
dashboard listens to l10n-mozilla-1.9.1 repositories.
Robert Kaiser
João Miguel Neves
In http://l10n.mozilla.org/dashboard/?locale=pt-PT I have sea20x red
with a link to
http://l10n.mozilla.org/buildbot/compare/hg-comm-langpack/8138
complaining about (for instance) the need to remove
menuitem.view.command.searchbar.accesskey
menuitem.view.command.searchbar.label
in pt-PT/suite/chrome/common/bookmarks/bookmarks.dtd
this keys do not exist on the 1.9.1 repo. They do exist in l10n-central.
Axel Hecht
> Robert Kaiser escreveu:
>> João Miguel Neves wrote:
>>> João Miguel Neves (EN) escreveu:
>>>> I can confirm that also for pt-PT the dashboard for sunbird is using
>>>> l10n-central
>>> And the same applies to seamonkey.
>> I can confirm that it doesn't apply to SeaMonkey. The sea20x tree on
>> dashboard listens to l10n-mozilla-1.9.1 repositories.
> Then there's something strange for pt-PT:
>
> In http://l10n.mozilla.org/dashboard/?locale=pt-PT I have sea20x red
> with a link to
> http://l10n.mozilla.org/buildbot/compare/hg-comm-langpack/8138
> complaining about (for instance) the need to remove
> menuitem.view.command.searchbar.accesskey
> menuitem.view.command.searchbar.label
>
> in pt-PT/suite/chrome/common/bookmarks/bookmarks.dtd
>
> this keys do not exist on the 1.9.1 repo. They do exist in l10n-central.
Yeah. I thought I bumped all local repos to 1.9.1, but some obviously not.
I pruned all local clones for the comm-central apps.
Axel