BuildID do not be precise!! - part 1 (in relation with l10n/build)

What is the BuildID? The BuildID represents the date and hour a build was generated. This allows us to identify a build; we could think of it as the Serial Number of a product which allows people to know things as in which factory and/or what date was produced.

When you select "about firefox" you can see the BuildID in there:
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0"

If you look at that number in bold, you can tell that the number represents a date YYYYmmDD and it has an extra 2 digits which represent the hour (HH) in which a build was generated.

This BuildID can also be found in the file application.ini that comes with your Firefox's installation:
[App]
Vendor=Mozilla
Name=Firefox
Version=3.0
BuildID=2008061004

One of the problems in here is that 2 different builds with (or without) different source code can have the same buildID if they happen inside the same hour. In the past, we were not able to generate two builds in less than an hour but nowadays we can and it happens that we can have to different builds with the same BuildID

NOTE: There are two bugs in which the meaning and the precision of the BuildID is being discussed. Bugs 431270 and 431905

L10n and the BuildID
We have lived many years with this and only this value. We have downloaded the binaries for years and we only had the reference on when that binary was created but nothing at all related to which Source Stamp, which files have been compiled in this build. We could only tell by looking at tinderbox logs and others.

There is people who needed to know what Source Stamp was used to generate that build and one of them is the L10n community, you knew it or not.

When we do generate the L10n repackages, we do download an en-US build, we checkout the en-US code and we do a configuration before running the repackage of the locale. Currently, we do checkout the latest en-US code BUT not the code that was used to generate that en-US build. This could mean that there can be several hours of difference in the Source Stamp and therefore we generate locales that are NOT exactly as the en-US build.

NOTE: This does not happen on releases since the code for en-US is frozen, but it does happen for nightly L10n repackages

Axel showed me a solution which reduces this gap between "the en-US Source Stamp used to generate the en-US build" and "the en-US Source Stamp used to generate an L10n repackage". The solution estimates out of the BuildID which could haven been the Source Stamp for that build by saying "let's assume it checked out at the beginning of the hour (Minute Zero of the hour)". This is better than what we have now since a BuildID that says the hour is HH, it could be a checkout of the Source Stamp HH:00 or HH:59

It is needed that we fix this and in the follow up blog post I will mention what I have been working on and as you might assume already it has to do by adding the Source Stamp to a binary.