Closed Bug 589444 Opened 13 years ago Closed 7 years ago

Add build date or buildID to about:support (and possibly about: and about:buildconfig)

Categories

(Toolkit :: General, defect)

Product:
Toolkit
Component:
General
Platform:
Other
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1109757

People

(Reporter: BenB, Unassigned)

References

(Blocks 1 open bug)

Details

Bug 572661 removes the build date from the User Agent string. However, it's still useful and needed for nightly testers and bug reports on bugzilla. Thus, is should be easily accessible for the user (not every website).

Bug 572661 comment 62, 11, 79 and others suggest to re-add this information in about:, about:support, about:buildconfig, and possibly Help | About, in a dedicated field. That's what this bug is about.
Component: Networking → General
QA Contact: networking → general
Blocks: about:support++
Bug 572661 has not been implemented, at least not yet. In its place we got bug 591537 which only applies to releases and betas, not nightlies where the build ID would be particularly needed. There's still the issue of non-mozilla.org builds with different build IDs, however.

The build ID was added to about:support via the UA string in bug 591776.

The current mockups for the new about dialog include the build date in human readable form. (bug 579547)
Blocks: 579547
Depends on: 572661
(In reply to comment #1)
> There's still the issue of non-mozilla.org
> builds with different build IDs, however.

Though, their releases should also have the frozen junk ID too.
This does not block bug 579547 in any way, IMO. The build ID will be in about:support, we're taking technical junk out of that dialog, not putting it back in.
No longer blocks: 579547
(In reply to comment #3)
> This does not block bug 579547 in any way, IMO. The build ID will be in
> about:support, we're taking technical junk out of that dialog, not putting it
> back in.

(In comment #1)
> The current mockups for the new about dialog include the build date in human
> readable form. (bug 579547)

I added it in reference to the build _date_ not build ID.
Blocks: 705335
Depends on: 600569
Resummarising since bug 588909 has been fixed.

Help -> About has the build date for non-release versions, and isn't going to get the buildID because it's a non-technical dialogue.

about:support is the main place that this should go. The main reason is for people filing bugs, as copying the UA is no-longer enough to show which build is being used.

about: is rarely used.

about:buildconfig could have the buildID as well as the changeset to show when the build started.
Summary: Add build date to about:, about:support, about:buildconfig, and possibly Help | About → Add build date or buildID to about:support (and possibly about: and about:buildconfig)
Blocks: 588909, 572661
No longer depends on: 572661
Blocks: 728773
No longer blocks: 588909
I would say we should add both build date and revision URL to about:support, and the build date to about:buildconfig, so they both display the same information.

I wouldn't worry about "about:". It has one-click access to build configuration anyway.

Gerv
Including Cheng to see if any documentation would need to change if the buildid was no longer advertised on about:support.
(In reply to Alex Keybl [:akeybl] from comment #8)
> Including Cheng to see if any documentation would need to change if the
> buildid was no longer advertised on about:support.

Note that the build ID (build date, really) was never part of about:support for release builds (it's frozen at 20100101). The build date is really only useful for nightly and aurora users, and bug 600569 added it to the about dialog for those builds.
The Build ID as stated in application.ini is unique (e.g., I see 20120215223356 for Firefox 10.0.2 Linux x86_64 release build) and is unrelated to the change which Firefox introduced to its UA string by freezing it a while ago.

While I agree that it's mostly of interest for the nightly and aurora channels, it's also relevant to distinguish beta versions. For the release channel, there are official Mozilla builds, contributed builds, Linux distributions' builds, and whatever other 3rd-party builds. Thus, it's a good identifier to resolve any ambiguity on the actual build which a user may be running.

As stated in bug 726587 comment #1, the respective code for this can be obtained from the about:support implementation Thunderbird (visible for all channels).
It's also useful for differentiating between respins.

To have the build id and user agent (which contains platform and architecture) in the same place will be more convenient for people filing bugs once the date gets taken out of the UA (although this bug can and should be fixed before that).

Something like (I don't have a build environment set up):

<tr>
  <th class="column">
    &aboutSupport.buildID;
  </th>
  <td id="buildID-box">
      
  </td>
</tr>

<!ENTITY aboutSupport.buildID "Build ID">

let buildID = Components.classes["@mozilla.org/xre/app-info;1"].getService(Components.interfaces.nsIXULAppInfo).QueryInterface(Components.interfaces.nsIXULRuntime).platformBuildID;

document.getElementById("buildID-box").textContent = buildID;

should work I think?
(In reply to rsx11m from comment #10)
> While I agree that it's mostly of interest for the nightly and aurora
> channels, it's also relevant to distinguish beta versions.

Wouldn't the changeset suffice?
There may be multiple builds from the same m-c changeset, e.g., if other repositories which are included in a change were modified. Thus, it's not as unique as the build ID (assuming that it's unlike you have more than one build started within exactly the same second).
rsx11m: if other repositories are modified, then surely something in the master repository also needs to change in order to pull in a different changeset from the other repository? Unless we are taking the somewhat brave step of always pulling from the tip of another repo?

The build ID is unique but it's not determinative - knowing that a build began at 20120215223356 doesn't tell me what it's made from. It helps me to know if two builds are the same or not, but it doesn't help me reproduce an exact copy of a build.

Does this mean we need both?

Gerv
How about a hg/git SHA commit ID in about:support?
Sorry, I missed comment 12/13.
rsx, I don't know about hg, but in git, the commit ID defines the whole source code, all changes, including merges.
For regression range tests, the commit ID would be highly useful. Once I have 2 nightly builds where one has the bug and the other doesn't, I still need to go from build date to hg commit log, and the transition is everything but precise, for the reasons you mentioned. In other words, what we really *need* is the hg commit ID, and any ambiguity not solved by the build system is one the individual dev needs to resolve, or he may even miss the ambiguity and look at the wrong changeset.

If one hg commit ID is not sufficient, then maybe add several. Whatever is necessary to identify the exact source code that went into a build. That's what the regression tester / dev needs.

The build date is also useful for other, more informal reasons, so we should add both.
(In reply to Ben Bucksch (:BenB) from comment #17)
> The build date is also useful for other, more informal reasons

That's why it's in the about dialog.
In some builds/channels yes, in others not. The combination of changeset(s) and build date/time should be sufficient to uniquely identify any build (under the assumption that it's unlikely that two builds are generated in the same second).

I yet have to see a convincing argument why the BuildID *shouldn't* be shown in the about:support page (as Thunderbird does it already for all channels), especially given that a code template is already provided.
(In reply to rsx11m from comment #19)
> In some builds/channels yes, in others not.

On channels where we think it makes sense. If you think it's missing on some channel, file a bug on that?

> The combination of changeset(s)
> and build date/time should be sufficient to uniquely identify any build
> (under the assumption that it's unlikely that two builds are generated in
> the same second).

Why would the changeset alone be insufficient to identify builds?

> I yet have to see a convincing argument why the BuildID *shouldn't* be shown
> in the about:support page

about:support should list stuff that's relevant for support. Cluttering it with redundant or irrelevant information doesn't help.
Everything was said above, thus no need to reiterate the points in favor of it.
Presumably you mean comment 13 -- which Gerv responded to in comment 14.
(In reply to Ben Bucksch (:BenB) from comment #16)
> rsx, I don't know about hg, but in git, the commit ID defines the whole
> source code, all changes, including merges.

Looking at mozilla-central, it appears that merges create their own changesets, so that should be a safe assumption. It remains an issue for applications that include comm-central components, and possibly other cases where multiple commit IDs would be present. That may be something to collect in about:buildconfig rather where the mozilla-* source is already stated (the nice thing about having these in the about:support page is obviously that his information is copy-pasted along with the other data, thus without the need to ask the user for action beyond that).

(In reply to Gervase Markham [:gerv] from comment #14)
> The build ID is unique but it's not determinative - knowing that a build
> began at 20120215223356 doesn't tell me what it's made from. [...]
> Does this mean we need both?

Strictly speaking yes. The same combination of changesets may have different builds, thinking of multiple candidate builds (sometimes users grab those) or specifically 3rd-party builds which may have their own modifications despite checking out the officially tagged releases. So, there are reasons to use both changesets and build information for unique identification, as said.
There's one major argument, IMHO:
While changesets are the better identifier in theory, it's easy to get them from about:buildconfig already right now anyhow, and they are completely unreadable for users or support people.
What I usually want to know (and a support person probably wants to know) is what day the Nightly or Aurora build is from, and "8c8346a7fae1" (or even the full URL) doesn't give a hint of a clue of that (sure you can then go and click through a few links (warning, the in the URL itself does NOT give you the push date relevant for us, but the commit date, which is comparingly random, given that it's taken from the clock on the developer's computer at the time he commits to his local tree) and after those couple of clicks I can arrive at the push date for the relevant changeset and I have what I want - at first, at plain sight of the changeset ID, I can't even tell if it's a couple of years old or from the current week.
The build ID, in comparison, gives the info of "from when the build is" just with a slightly closer look. And because it's going down to the second, it's unique enough for comparisons as well. Also, we are using the build ID in a couple of places, for example crash reports, and it proves quite helpful for analysis there.

So, IMHO, for support, the build ID is way more helpful than the changeset - and we can get the latter from about:buildconfig already anyhow if we're interested in it, while we have no quick way of getting the build ID (short of looking for application.ini and digging it out from there).
The bug below has recently re-landed on Nightly 15.0a1 builds making this Bug 589444 more relevant and needed now,

Bug 588909 - Replace Gecko/<date> with Gecko/<version> in UA string
Product: Core → Toolkit
No longer blocks: 728773
The build ID was added in bug 1109757.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.