{"id":366,"date":"2011-04-11T18:15:03","date_gmt":"2011-04-12T01:15:03","guid":{"rendered":"http:\/\/blog.mozilla.org\/axel\/?p=366"},"modified":"2011-05-04T10:33:31","modified_gmt":"2011-05-04T17:33:31","slug":"being-a-localizer-in-the-rapid-release-cycle","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/axel\/2011\/04\/11\/being-a-localizer-in-the-rapid-release-cycle\/","title":{"rendered":"Being a localizer in the rapid release cycle"},"content":{"rendered":"

We’re changing to a 6-week release train model<\/a>, 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.<\/p>\n

Recap on the rapid release cycle: en-US developers work on mozilla-central<\/em>, as they used to, and every 6 weeks, we’ll pull their contributions to another repository, called mozilla-aurora<\/a>. That repository is string frozen. String changes only land in this repository as part of the merge from central<\/em> to aurora<\/em>. After another 6 weeks, the content goes to yet another repository, mozilla-beta<\/em>. Corresponding to those, there’s l10n\/mozilla-aurora<\/em> and l10n\/mozilla-beta<\/em>. And now you know. Find a glossary at the end of this post.<\/p>\n

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.<\/p>\n

Early Birds<\/strong> are those localization teams that are happy to follow the mozilla-central<\/em> 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 are crucial to make the plan work, and have code that is properly localizable at any time on aurora<\/em>. You’ll be following the fx_central tree on the l10n dashboard to catch up on changes.<\/p>\n

Friends of String Freeze<\/strong> 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<\/em> clone, your l10n\/mozilla-aurora<\/em> 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.<\/p>\n

Sign-offs will happen on aurora<\/em>, in rare cases on beta<\/em>. The setup where we work towards release is aurora<\/em>.<\/p>\n

What about the beta<\/em> repositories? Well, I hope to not see a necessity to land on l10n\/mozilla-beta<\/em> for the most part. You should expect that changes you make on l10n\/mozilla-beta<\/em> will be dropped once we do the next update from aurora<\/em>, so you want to have the fixes on both aurora<\/em> and beta<\/em>, if applicable. But really, you want to be good on aurora<\/em>. Then beta<\/em> will be fine and no hassle.<\/p>\n

How that maps to mercurial work:<\/strong><\/p>\n

For the Friends of String Freeze<\/strong>, you’ll not need to worry about anything other than pulling on both repos every cycle. We’ll take your content from l10n\/mozilla-aurora<\/em> to l10n\/mozilla-beta<\/em>, and may very well at some point stop doing l10n-central<\/em> builds at all for you. Just keep things simple here.<\/p>\n

For the Early Birds<\/strong>, 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<\/em> to l10n\/mozilla-aurora<\/em>, making sure that the result has all your fixes from both central<\/em> and aurora<\/em>, 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\/mozilla-beta<\/em> anymore than the rest, though.<\/p>\n

Glossary<\/strong>:
\nmozilla-central<\/em><\/a> is the mercurial repository that en-US code is landed to as development makes progress.
\nl10n-central<\/em><\/a> is the tree of mercurial repositories that the early-bird localizers use as development makes progress.
\ncentral<\/em> is short for either, or both, of mozilla-central and l10n-central, depending on context.<\/p>\n

The terms around mozilla-aurora<\/em><\/a>, l10n\/mozilla-aurora<\/em><\/a>, and aurora<\/em> map to their corresponding terms for central<\/em>, same for mozilla-beta<\/em><\/a>, l10n\/mozilla-beta<\/em><\/a>, and beta<\/em>.<\/p>\n

Update<\/strong>: Fixed the links to map to the new and stable repository locations.<\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":17,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,5],"tags":[23779,23778],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/posts\/366"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/comments?post=366"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/posts\/366\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/media?parent=366"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/categories?post=366"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/axel\/wp-json\/wp\/v2\/tags?post=366"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}