214295 - The gecko date string or ID is the build date, not the maturity of gecko engine

Status: NEW

(Core :: Layout, defect)

Description

[Ben Fowler]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030728
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030728

See date string (HTTP User Agent ID) above.

This was compiled today, but checked out over a week ago. So far as I can tell,
this is mentioned in Bug 83405, but nowhere else. Fundamentally, it makes the 
ID string the dfate that gecko was last linked, which is not terribly important.

Surely the vital date is the date that the gecko sources were last committed
prior to being checked out by the builder. This should be accessible as the
$Date$ CVS keyword of some central gecko file or a CVS Tag.

Given that as hinted above, nobody has noticed this before, I assume that 
I am unaware of some vital factor, but I would have thought that this was worth
documenting.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.




Perhaps bugzilla needs a level of severity - Nitpicking.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Surely the vital date is the date that the gecko sources were last committed
> prior to being checked out by the builder.

How is this to be updated when check-ins happen (about every hour or two)?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Also, see discussion in bug 26798

Comment 3

[Ben Fowler]

Replying to #1.

The 'how' is by picking up the check-in date for some key source
or header file or change log for Gecko. This is a monotonically increasing
value that represents maturity.

It is not part of my suggestion that one should attempt a finer resolution
than this, in the way that the Camino nightlies have a two digit suffix
after the date string.

If you don't think that this is of value, then fair enough, but it does
mean that the string reflects the time that the Gecko library
was recompiled/linked and can be months after the date that the code
was pulled. I would have thought that this would make bug and regression
tracking troublesome.

It would most certainly be a preference of mine to have the User Agent/Build
String show the checkin date of Gecko ($Date$) and not the date that I 
personally built that library.

Perhaps not that many people compile their own Lizards and report bugs ...

If I am making an unoffical build, I am quite happy that numbers and strings
are in a separate 'number space', but I would have thought that you would have
preferred that quotable, and transmitted numbers bore a proper relationship
to reality.

Now that you have provided the discussion, you can resolve this as WONT FIX
assuming that nobody else objects.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We could have a daily auto-commit.  This would be useful for "dotting" the date
on branches, too...

Comment 5

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041111
Firefox/0.9.1+

I looked at this again after I discovered that two check-outs and builds 
yesterday had PRODUCT-VERSION "20041111".

It seems that after the work in relation to Bug 83405 (see comments
17 et sequentes), this report is irrelevant.

It should be closed as RESOLVED FIXED (by checkins above) or RESOLVED
WORKSFORME, as the problem is gone.

(I am guessing that removing the gbdate.tstamp file will resolve the
discrepancy that brought me here I am re-spinning)