Tryserver builds should be rebranded to be trivially distinguishable from any release channel.

NEW
Unassigned

Status

()

Core
Build Config
22 days ago
19 days ago

People

(Reporter: mhoye, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

22 days ago
Right now try server builds are difficult to distinguish from nightly release channel builds. For example, one calls itself "Firefox Nightly", and the other "FirefoxNightly", no space.

We periodically have community members using try builds to reproduce bugs, and this can potentially fail in two directions: "user provides test feedback on wrong build" and "user gets stuck  with a try build as their daily driver", neither of which are great.

In order to avoid confusion, I propose that:

- Try builds be explicitly branded as such - Try-Firefox-[bug] or -[date] so we can avoid that confusion, and if at all possible,

- They have Dogefox as an icon instead of anything else. 

That second part isn't really required, but it would be so good. 

Thanks.
This is basically what bug 659568 was about, but got stalled in naming (bug 682415).
(Reporter)

Comment 2

22 days ago
RESOLVED DOGEFOX
There's definitely an element here where every bit we make try builds different from the stuff we build elsewhere is one more thing that can break on inbound/central and not try, but I think that's manageable if we give people an opt-out that lets them generate try builds that do match the stuff we ship exactly. There are also folks that do builds on try that match beta/etc because of existing build differences there, and we've been trying to get better about making that easy.

That being said, to make this happen we'd need:
1) Some new branding bits to go under browser/branding to use: https://dxr.mozilla.org/mozilla-central/source/browser/branding/
2) Something to communicate to the build system that this is a try build and not another branch. We don't have much of this currently, but the decision task does know this. It uses it to make artifacts from try builds expire more quickly, for example: https://dxr.mozilla.org/mozilla-central/rev/7b46ef2ae1412b15ed45e7d2367ca491344729f7/taskcluster/taskgraph/transforms/task.py#1433
3) The in-tree mozconfigs would need to select the proper branding. Right now all "opt" builds use the "nightly" mozconfig, and those explicitly set `--with-branding=browser/branding/nightly`, like: https://dxr.mozilla.org/mozilla-central/rev/7b46ef2ae1412b15ed45e7d2367ca491344729f7/browser/config/mozconfigs/win32/nightly#6

If you want dynamically-generated info in the branding like a bug number or date that will probably require a bit more work, but the above should be pretty straightforward.
There was also a recent regression/change around this which caused me to file bug 1416538. Artifact builds on try still use the unofficial branding but non-artifact started using official branding last year. I pointed to the (potential) cause of the OS X regression in that bug.
See Also: → bug 1416538
Also, related to bug 1416538, for the sake of screenshot comparisons between try and integration/m-c, non-Nightly builds on try should use the same branding as non-Nightly integration/m-c builds.
You need to log in before you can comment on or make changes to this bug.