L10n build presentation slides

Thanks everyone who attended the "L10n build process" presentation at the Summit 08.

This the presentation that was used for the session, please contact me if something does not make sense:



These are some of the notes/feedback that I got from the discussion with the rest of the localizers:
- No back check-in to locale's repository
- Generate installer with missing string so the installer does not break
- Modify the branding if the locale is missing entities
- Add Source Stamp in "About" for better litmus testing

The last two notes/suggestions are not at hand right now and they will be worked on in due time

Make our nightly builds identical for each platform - part 1

The way we do nightly builds every night for Firefox 2.0.0.x and Firefox 3.0.x have few problems that will be good to have them fixed.

1. The build for each platform happens AFTER a determined hour BUT whenever the build slave can start it. Therefore, the build start time is different from platform to platform. This will be even more obvious when the buildID will capture minutes and seconds. This is not a big problem but it is not a correct behavior and it would be good to have the same buildID for all 3 platforms.
   
2. The build for each platform is NOT build from the same source code. You knew it or not, this has been happening for many years. This is a big problem specially when a commit to the source code happens around the time that the nightly builds are to happen and this change might be captured by one platform and not by the others. This problem affects when you want to see if a bug introduced in one of the platforms is part of the other two platforms

Things we are doing to improve this

1. Separating the generation of nightly builds from generating dependent builds
   For years, we have generated dependent and nightly builds from the same slave running the exact same code all day. We generate nightly builds after the last dependent build that gets finished after 3AM PDT. Each platform finishes at different time and each platform checks out different source code. To be more precise a nightly build is started if 1) it is passed the $build_hour and 2) twenty four hours have passed since the last nightly build. To stop the dependt builds process to generate nightly builds we need to set $OfficialBuildMachinery to zero in the tinder-config.pl
2. Use Nightly scheduler to trigger nightly builds
   Using a nightly scheduler will allow us to add more steps after an en-US nightly build like trigerring L10n repackages and/or trigger other schedulers as needed
   
3. Setting the checkout time before the build starts
   If we set up the same MOZ_CO_DATE for the 3 different platforms before the build start they will check out the same source stamp no matter when the slave will start the build
   
4. Remember the checkout time
   Saving the SourceStamp inside of the application.ini file will allow us to know which SourceStamp was used for that build even if the log for that build gets removed from the tinderbox logs

How would things look like after these changes?





















As the image shows:

1. Our nightly builds will not depend on previous dependent builds
2. The nightly builds will be triggered when we say
3. The nightly builds will check out the same source code
4. From a binary we will know which source stamp was used to generate the build
   

SourceStamp in application.ini (it helps the L10n process)

As I mentioned in my previous blog post, when we do L10n repackages it happens by unpackaging an en-US build and overwriting the en-US dtd and property files with the ones of that locale.

Part of this process requires checking out part of the en-US code and the current problem is that we do NOT checkout the same Source Stamp than what was used to generate the en-US build, since we do not really have a way to know what was the Source Stamp used.

There is a bug which I started to work on last week and the patches would allow us to have the Source Stamp in application.ini if a MOZ_CO_DATE variable is set when checking out the source code. Therefore, if we have this working we will have it easy to know what Source Stamp was used for an en-US build and we will be able to check out exactly the same Source Stamp when doing L10n repackages and we should not be unsynchronized at all.

NOTE: The previous patches mentioned do not change anything at all if no MOZ_CO_DATE is set.