Let's get a bug on file to do "release automation" for l10n. I'm bluntly re-using the term "release automation" here, 'cause I think it's really just extending the existing release automation to include the l10n release process that predates the builds. Right now, release automation for l10n starts with shipped-locales. That file used to be generated by hand, but the complexity of our localizations got to the point where that became error prone and frustrating, so I started to automate the things I did by hand. Sounds familiar? Here's the deal: For a particular release of a particular product, the following criteria go into the decision on whether to ship a locale or not: 1) Builds a) localization completeness, and as far as possible, technical correctness b) successful builds 2) QA a) web-services/productization is valid and approved b) litmus tests run by localizers c) overall testing feedback as reported by localizers d) QA team testruns and spotchecks 3) Localizer sign-off There are some undocumented rules about extending some of that data from one release to the next minor update of that release, for example QA and sign-off. The existing process is still partly relying on manual work, which is error prone, and doesn't scale. Even just keeping track of sign-ons failed ever again. Thus, it's essential that - all data is first-hands - is machine-readable - has as few single points of failure as possible. There is work going on in bug 408331 to automate gathering data on litmus tests, and there is existing work to make 1) work reliably on l10n.mozilla.org. Most of the QA work is currently tracked in google spreadsheets, as is the sign-off, which is then read in by a exhibit, together with compare-locales data from l10n.m.o and second-hand data from tinderbox (failed to catch linux l10n problems for RC2, btw). So much for *my* initial comment, others?

Are you proposing that this l10n-driver-automation be strongly connected with the automation that produces builds ? Seems to me that those should stay separate and be connected by shipped-locales. Perhaps this should live in Mozilla Localizations::Infrastructure ?

Axel: where do we stand with this bug now after the progress of the past year? We still have some issues with shipped-locales AIUI.

I'm resolving this incomplete because we've done a ton of our work on l10n systems in the past 2 years, and I have no idea whether or not any of this has been addressed. I feel like this bug has no good reason to stay open. Please re-open if you disagree.

Reopening. This is about getting the hooks between what's automated on the 1l0n side together with what's automated on the releng side. We're getting a tad closer with the dropping of shipped-locales for maemo, but we're not there yet.

Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

(In reply to comment #4) > Reopening. > > This is about getting the hooks between what's automated on the 1l0n side > together with what's automated on the releng side. > > We're getting a tad closer with the dropping of shipped-locales for maemo, but > we're not there yet. Axel, Found in triage. Lots have changed and already been refactored in RelEng automation for l10n since 2008. There's also bug#562903. Can you specify what exactly you want done here?

(In reply to comment #6) > (In reply to comment #4) > > Reopening. > > > > This is about getting the hooks between what's automated on the 1l0n side > > together with what's automated on the releng side. > > > > We're getting a tad closer with the dropping of shipped-locales for maemo, but > > we're not there yet. > > Axel, > > Found in triage. Lots have changed and already been refactored in RelEng > automation for l10n since 2008. There's also bug#562903. Can you specify what > exactly you want done here? Axel; ping?

(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #4) > > > Reopening. > > > > > > This is about getting the hooks between what's automated on the 1l0n side > > > together with what's automated on the releng side. > > > > > > We're getting a tad closer with the dropping of shipped-locales for maemo, but > > > we're not there yet. > > > > Axel, > > > > Found in triage. Lots have changed and already been refactored in RelEng > > automation for l10n since 2008. There's also bug#562903. Can you specify what > > exactly you want done here? > > Axel; ping? Axel: ping?

I think we're mostly there.