[ANNOUNCE] Being a localizer in the rapid release cycle
Axel Hecht
http://blog.mozilla.com/axel/2011/04/11/being-a-localizer-in-the-rapid-release-cycle/,
which reads with better markup and links, copied only for quoting.
We’re changing to a 6-week release train model, and this is going to
impact how localizers do their contributions. The following scheme has
been cycled in .planning for a bit, so this is what we’ll be doing.
We’ll adapt that if needed, of course, but based on experience with the
next cycle or two.
Recap on the rapid release cycle: en-US developers work on
mozilla-central, as they used to, and every 6 weeks, we’ll pull their
contributions to another repository, called mozilla-aurora. That
repository is string frozen. String changes only land in this repository
as part of the merge from central to aurora. After another 6 weeks, the
content goes to yet another repository, mozilla-beta. Corresponding to
those, there’s l10n-aurora and l10n-beta (TBD). And now you know. Find a
glossary at the end of this post.
There are two different localizer schemes: Early birds and friends of
string freeze. Read the following descriptions and pick one for your
individual localization team.
Early Birds are those localization teams that are happy to follow the
mozilla-central content quickly and make sure that all issues relating
to localizing that code are found and fixed. We already have a few of
those that have built their reputation among our hackers to have good
input to follow. We don’t need a lot of those, but the ones we have a
crucial to make the plan work, and have code that is properly
localizable at any time on aurora. You’ll be following the fx_central
tree on the l10n dashboard to catch up on changes.
Friends of String Freeze are those teams that prefer to have stable
content to localize with a decent time window to act on it. Many of our
localization teams are in this group. If you’re in this group, you’ll
set your calendar alarm to the next window, hg pull -u on your
mozilla-aurora clone, your l10n-aurora clone, localize, push, test, fix,
push, sign-off. Then you set your calendar to the next 6-week cycle, and
you’re all set. The expectation here is that the amount of strings will
be rather low, so a day of l10n plus testing and fixing is fine.
Usually, you should be able to deliver a great localization for the next
version of Firefox in some 3 days. Firefox 5 right now is some 30
strings, other releases will be a good deal bigger. But nowhere close
the 1.2k strings of Firefox 4. You’ll be watching the fx_aurora tree on
the l10n dashboard to see the status of your localization.
Sign-offs will happen on aurora, in rare cases on beta. The setup where
we work towards release is aurora.
What about the beta repositories? Well, I hope to not see a necessity to
land on l10n-beta for the most part. You should expect that changes you
make on l10n-beta will be dropped once we do the next update from
aurora, so you want to have the fixes on both aurora and beta, if
applicable. But really, you want to be good on aurora. Then beta will be
fine and no hassle.
How that maps to mercurial work:
For the Friends of String Freeze, you’ll not need to worry about
anything other than pulling on both repos every cycle. We’ll take your
content from l10n-aurora to l10n-beta, and may very well at some point
stop doing l10n-central builds at all for you. Just keep things simple here.
For the Early Birds, we’ll rely on you self-identifying and doing a tad
of extra work. You’ll be in best shape to merge your contributions from
l10n-central to l10n-aurora, making sure that the result has all your
fixes from both central and aurora, where you want them. You’re
techy-geeky-savvy anyways, so that’s allright. If at some point, we
learn that there’s a pattern that benefits from automation, we’ll check
in on that when we get there, too. You shouldn’t have to worry about
getting content on l10n-beta anymore than the rest, though.
Axel
PS:
Glossary:
mozilla-central is the mercurial repository that en-US code is landed to
as development makes progress.
l10n-central is the tree of mercurial repositories that the early-bird
localizers use as development makes progress.
central is short for either, or both, of mozilla-central and
l10n-central, depending on context.
The terms around mozilla-aurora, l10n-aurora, and aurora map to their
corresponding terms for central, same for mozilla-beta, l10n-beta, and beta.
Anas Husseini
So far so good. I have several miscalleneous questions:
1- Any change on the sign-off policy? For instance, is signing-off one
particular aurora a prerequisite for opting in its corresponding beta? Is
there a minimum number of signed off betas needed for signing off a stable?
Any other rules or tips?
2- I understand that the majority of string changes will appear on the merge
between central and aurora every 6 weeks. The merge between aurora and beta,
or beta and stable will yield to little or no string changes (changes coming
from blocker bugs). That said, will there be an automatic sign-off method
that enables aurora-green locales to appear on beta through a l10n merge.
3- I guess the stable releases will currently remain under
releases/mozilla-X.X , right?
4- I wonder if one l10n repo with 4 branches (or 3 branches, not counting
stable) isn't better than 4 separate repos. It will be easier for localizers
to merge changes between two branches that way.
Regards
Anas
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>
Axel Hecht
> Hi Axel,
>
> So far so good. I have several miscalleneous questions:
>
> 1- Any change on the sign-off policy? For instance, is signing-off one
> particular aurora a prerequisite for opting in its corresponding beta? Is
> there a minimum number of signed off betas needed for signing off a stable?
> Any other rules or tips?
You'll sign off on aurora, which will be your sign-off for beta. That
does imply that we break up the strong ties between sign-offs and
repositories that are currently there. That's mostly technical back end
work, and doesn't really impact where we're going with the UI of it.
> 2- I understand that the majority of string changes will appear on the merge
> between central and aurora every 6 weeks. The merge between aurora and beta,
> or beta and stable will yield to little or no string changes (changes coming
> from blocker bugs). That said, will there be an automatic sign-off method
> that enables aurora-green locales to appear on beta through a l10n merge.
That will depend on the string changes that land, and the locale. We
will not do that automatically, in particular if multiple cycle of
non-localized strings pile up. The good news is, we know exactly when
that happens and can start outreach early. Which we will.
> 3- I guess the stable releases will currently remain under
> releases/mozilla-X.X , right?
No, the releases/... repos will be not used anymore. The reason for that
is that our maintainance policy changes, the next security update for fx
5 is fx 6, unless there's a chemspill. In general, though, some version
of Firefox will be supported some 6-12 weeks, and then it's done with.
> 4- I wonder if one l10n repo with 4 branches (or 3 branches, not counting
> stable) isn't better than 4 separate repos. It will be easier for localizers
> to merge changes between two branches that way.
In-repo named branches may be easier to work with for technical folks,
but I think that for non-technical folks, it can get confusing really
quickly. Also, I recommend looking at the transplant extension that's
shipped with mercurial. That allows you to pull a changeset from one
repo to the other in just one command. Overall, I expect that the
majority of folks really ever have one repo they work on, though.
Axel
Anas Husseini
rapid cycle on Firefox Mobile?
Anas
Axel Hecht
http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/67c98051710aa67/cef7bb3b258ea4b5?lnk=gst#cef7bb3b258ea4b5
Things will be very similar, aka, you'll also focus on aurora for l10n,
or self-select to follow central.
Axel