User:AxelHecht/L10n build deliverables

This page brings together User:AxelHecht/L10n build tasks and User:AxelHecht/Building l10n to propose a list of deliverables coming out of the build and release infrastructure.

Before proposing a set of priorities, the

Milestones

are ...

Release builds

Release builds are builds made to be shipped as products, including the actual release builds, as well as pre-releases like alpha, beta, RCs, as well as the candidate builds for these.

Release builds need to be

• completely localized
• vetted by the l10n team through sign-off
• build successfully
• pass runtime tests

Release builds should upload the the candidate directories.

Nightly builds

Nightly builds are builds offered to early adopters to follow our development process. They both serve our engineering community to test new gecko and product features on an international audience as well as providing a lively testing community for our localization teams.

As these are development builds, it's not feasible to assume that each locale will be 100% updated at the point when these builds are done. Thus it's important that these builds go through l10n-merge to provide feedback on the previous work by the localization team as well as the main engineering community.

Nightly builds need to be

• l10n-merged
• build successfully
• pass runtime tests
• creating full and incremental mars

Nightly builds should be uploaded to tinderbox-builds, latest-foo-l10n, and the infrastructure for the nightly update channel.

Development builds

Development builds are created on change of localizers. These try to map the following nightly as closely as possible, and thus provide feedback to the localizer on how likely the following nightly is going to work, and how his changes are going to look for the end-user. Due to the imminent window between an en-US code landing and en-US builds being available for repackaging, there is no way to be 100% error free here. As such, running l10n-merge is again key for these builds to be useful.

As our l10n community is much more fragmented, with more challenges in connectivity throughout the world, response time is essential for these builds. There just isn't a sheriff around or anybody else in #developers that can just fix a bustage. Or back you out. The experience on the l10n server shows that response times of 5 minutes from check-in to build result are feasible.

Development builds need to be

• l10n-merged
• build successfully
• pass runtime tests

Development builds should be uploaded to tinderbox-builds.

en-US notifications

For our development model, notifying the localization community about outstanding work is important. The timelier that notification is published, the better the quality of nightly builds can be. In the case of ramping down to a release, the lag of notifications determines the timing for late l10n changes.

Thus we should do a compare-locales run on en-US check-ins. It makes more sense to me to do those on check-in than on build-availability. For one, check-in is earlier, and the build-availability depends on platform, while missing strings don't really. Doing this on check-in does imply that creating real builds is of now use, though, thus this is only a "build" in buildbot terms, not in a uploadable binary deliverable.

en-US-notifications need to be

• running compare-locales, tip against tip

Now that we have a list of deliverables, let's put some priorities to them.

Priorities

The premier priority is of course the release builds. In order to check for a complete localization, these builds need to pass a compare-locales test, with the tagged source revisions.

Nightly builds and development builds come with the same technical demands on the actual build process, and are merely differing in the scheduling. As being able to distribute a nightly requires the localizer to get feedback from the development builds, there is no difference in priority between the two.

en-US-notifications are in a third level. While being essential in clearly documenting the work that needs to be done by our localization teams, not doing this merely delays that to the next nightly. On the other hand, it's also the cheapest build.

The individual requirements in these deliverables can be prioritized, too. I'll leave that for a detailed discussion.