[Announce] Firefox 3.1 Beta 3 tagged, mind your step
Axel Hecht
please note that the releases/l10n-mozilla-1.9.1 repos participating in
the Firefox 3.1 Beta 3 release have been tagged.
The tags themselves have been pushed to changesets on a relbranch,
GECKO191b3_20090304_RELBRANCH.
For most of you, this branch should be off an old changeset, so doing a
hg pull
hg update -r default
should be all that's needed.
If your branch tag happens to be the former tip, you might need to force
on your next push to default.
Versions of hg > 1.1 should play nicer here in both scenarios. You
should consider updating your version of hg. There is a TortoiseHG
release with 1.1+ as well now.
Please don't merge the head on the relbranch to default. That's not what
the relbranch is good for.
If your central and 1.9.1 repos are out of sync, you shouldn't consider
pushing these changes to central. If they are, you should consider not
pushing them either. From a release engineering point of view, that
wouldn't be right, and from an hg versioning point of view, it's not
required. It might require that you do something like
hg push -r default central
if you have the central alias entered in your .hg/hgrc in your 1.9.1
repo like I suggested back when we opened 1.9.1. Again, this does only
make sense if your central and 1.9.1 repo are still in sync.
PS: The thunderbird tags were sadly not on a relbranch, which doesn't
offer this scheme for those tags.
If you have questions, ask here or on #l10n.
HTH
Axel
Robert Kaiser
> PS: The thunderbird tags were sadly not on a relbranch, which doesn't
> offer this scheme for those tags.
Why "sadly"? Not having a relbranch but just a plain tag avoids all
those problems from the beginning, doesn't it?
Robert Kaiser
Axel Hecht
Nick started an email thread on this, which I think we should take to
.tree-management.
The issues isn't about branch or not, the disturbance in the force is
coming from the tag in the upstream repo, at which point most localizers
are unexpectently forced to actually pull.
Whether they plain merge or plain update doesn't really matter.
It'd matter less still if we'd actually distribute a not-so-buggy
version of hg with MozillaBuild, too.
The radical question is "why do we tag?". Which we should discuss in
.tree-management, IMHO.
Axel
Stefan Plewako
> Whether they plain merge or plain update doesn't really matter.
Sorry Axel but IMHO you are completely wrong here.
Plain updating is simple, not disturbing, task that most of us (like when team has more then one contributor) is performing before every commit. Dealing with branches on the other hand, even if you know that stuff and have some experience with it, is like fighting with hydra - you are updating, spotting new heads (if not then you fail immediately) and then you spent to much time on it, to often fail and the time most efficient method is clean start...
Mercurial branches are simply broken and we shouldn't use them, at least for l10n.
Stef
--
Aviary.pl l10n team
http://www.aviary.pl
Axel Hecht
I might sound like a broken record, but DO UPDATE YOUR HG CLIENT.
Those bugs are FIXED.
Don't make calls on old versions of software.
Axel
Stefan Plewako
> I might sound like a broken record, but DO UPDATE YOUR HG CLIENT.
>
> Those bugs are FIXED.
>
> Don't make calls on old versions of software.
I'm afraid you are missing the point.
FYI: I use 1.1.2 right now and will update to 1.2 as soon as it will be available to me.
EOT
Robert Kaiser
I don't recall that ending up on the wrong branch with a pull and update
is just a version issue, it's an issue of design and dealing with
branches no matter what the version is, AFAIK.
From all I've seen, plain tags are much easier to deal with in normal
workflow than named branch branches, so IMHO we should try using just
those and avoid relbranches where possible - and I don't really see the
need for relbranches in L10n repos (yet).
Robert Kaiser
Дамјан Георгиевски
> update is just a version issue, it's an issue of design and dealing
> with branches no matter what the version is, AFAIK.
>
> From all I've seen, plain tags are much easier to deal with in normal
> workflow than named branch branches, so IMHO we should try using just
> those and avoid relbranches where possible - and I don't really see
> the need for relbranches in L10n repos (yet).
Using branches wit Mercurial seems to me like emulating the CVS pain all
over again.
--
дамјан ( http://softver.org.mk/damjan/ )
Spammers scratch here with a diamond to find my address:
|||||||||||||||||||||||||||||||||||||||||||||||
F Wolff
> Hi all,
>
> please note that the releases/l10n-mozilla-1.9.1 repos participating in
> the Firefox 3.1 Beta 3 release have been tagged.
>
> The tags themselves have been pushed to changesets on a relbranch,
> GECKO191b3_20090304_RELBRANCH.
Hallo all
Since I don't really follow the discussion in the rest of the thread
about the relative merits of different approaches, I'll put an unguided
vote in for whatever will allow me to have the faintest chance to ever
explain this to a non-technical translator.
We've had some interest from people in currently unsupported languages,
but this part of the process continues to be beyond any complexity I've
needed to master in any other project. As some people in IRC would know,
my last two commits collectively took several hours due to struggling
with mercurial errors that were eventually only solved with a fresh
clone (each time). And this was just for beta releases. I've been
translating GNOME for several releases, and don't even have commit
access yet - the process can be that simple for GNOME if needed.
So I believe we should continue to think of ways in which we can
simplify our process. I don't think we really need to anticipate
advanced branching requirements or similar VCS features as needed by
developers (which I think is what Robert was saying).
Keep well
Friedel
--
Recently on my blog:
http://translate.org.za/blogs/friedel/en/content/video-virtaals-functionality
Axel Hecht
> Axel Hecht wrote:
>> On 05.03.2009 16:51 Uhr, Stefan Plewako wrote:
>>> W dniu 05.03.2009 15:48, Axel Hecht pisze:
>>>> Whether they plain merge or plain update doesn't really matter.
>>>
>>> Sorry Axel but IMHO you are completely wrong here.
>>>
>>> Plain updating is simple, not disturbing, task that most of us (like
>>> when team has more then one contributor) is performing before every
>>> commit. Dealing with branches on the other hand, even if you know that
>>> stuff and have some experience with it, is like fighting with hydra -
>>> you are updating, spotting new heads (if not then you fail immediately)
>>> and then you spent to much time on it, to often fail and the time most
>>> efficient method is clean start...
>>>
>>> Mercurial branches are simply broken and we shouldn't use them, at least
>>> for l10n.
>>
>> I might sound like a broken record, but DO UPDATE YOUR HG CLIENT.
>>
>> Those bugs are FIXED.
>>
>> Don't make calls on old versions of software.
>
> I don't recall that ending up on the wrong branch with a pull and update
> is just a version issue, it's an issue of design and dealing with
> branches no matter what the version is, AFAIK.
Actually not. 'pull' being brittle was a version issue, and the idea
that pulling "tip" instead of "default" was just ill-advised. Which is
what lead us to the problem of relbranches et al. (If you happen to run
across docs that talk about "tip", please revise.)
With a current version of hg, you should just pull (and it might tell
you about the new branch)
> From all I've seen, plain tags are much easier to deal with in normal
> workflow than named branch branches, so IMHO we should try using just
> those and avoid relbranches where possible - and I don't really see the
> need for relbranches in L10n repos (yet).
IMHO, relbranches would be just simple (as opposed to having to do
merges), if only the hg folks wouldn't have insisted on not fixing
http://www.selenic.com/mercurial/bts/issue736 (yet). Grump.
That's leading to the following error message on push:
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
which has nothing to do with the situation you're in.
It does that if and only if you haven't actually checked anything in yet
since the sourcestamp that you handed in for release, though. Which most
folks will not be affected by.
Axel