Intent to remove "-e10s" from treeherder group symbols and task labels

[Andrew Halberstadt]

Hi everyone,

Almost all of our tasks in CI now run with e10s enabled, we only run
non-e10s
with Fennec and Linux32. Yet the "default" state in terms of our CI, is
still non-
e10s. You can see this by the presence of "-e10s" suffixes in task labels
and
treeherder symbols.

To better reflect reality, I'd like to switch things around such that "e10s"
becomes the default state and non-e10s tasks are the ones that need special
labeling. In bug 1541527
<https://bugzilla.mozilla.org/show_bug.cgi?id=1541527> I have a patch that
removes all "-e10s" suffixes from
treeherder symbols and task labels, and adds a new "-fc" suffix to non-e10s
tasks.

This change could potentially cause disruptions to things like saved |mach
try
fuzzy| presets or ActiveData queries that depend on the task label. *If you
can*
*think of any other possible reasons to hold off from landing please let me*
*know!* I'll wait a week for comment.

Why -fc?

The electrolysis of water is the process of using electricity to break down
water
molecules into hydrogen and oxygen. A fuel cell is a device that can use
oxygen to convert the chemical energy of hydrogen into electricity, aka the
reverse process as electrolysis. Therefore "-fc" stands for "fuel cell", the
opposite of e10s. This is why engineers shouldn't be allowed to name
things..
other suggestions welcome.

Let me know if you have questions or concerns!
Thanks,
Andrew

[Sylvestre Ledru]

Le 09/04/2019 à 21:26, Andrew Halberstadt a écrit :
> Hi everyone,
>
> Almost all of our tasks in CI now run with e10s enabled, we only run
> non-e10s
> with Fennec and Linux32. Yet the "default" state in terms of our CI, is
> still non-
> e10s. You can see this by the presence of "-e10s" suffixes in task labels
> and
> treeherder symbols.
>
> To better reflect reality, I'd like to switch things around such that "e10s"
> becomes the default state and non-e10s tasks are the ones that need special
> labeling. In bug 1541527
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1541527> I have a patch that
> removes all "-e10s" suffixes from
> treeherder symbols and task labels, and adds a new "-fc" suffix to non-e10s
> tasks.

Thanks for doing that!

> This change could potentially cause disruptions to things like saved |mach
> try
> fuzzy| presets or ActiveData queries that depend on the task label. *If you
> can*
> *think of any other possible reasons to hold off from landing please let me*
> *know!* I'll wait a week for comment.
>
> Why -fc?

What about "non-e10s"? I think code names aren't great for new comers
and just make their life harder.

Sylvestre

[Andrew Halberstadt]

Yeah, I did consider "non-e10s" for awhile and maybe it is the better
choice. But here are my counter arguments:

1) One of the goals of this change is to de-clutter the treeherder UI.
Using an 8 character symbol suffix runs counter to that goal (even if it is
still less cluttered overall).
2) People who use "e10s" in their |mach try fuzzy| queries out of muscle
memory (or in saved presets) will accidentally select the exact opposite of
what they want.
3) For new contributors "e10s" is a code word anyway. It's just now they
need to learn "fc" instead of "e10s".

None of those are terribly compelling, but it's still enough to make me
prefer "-fc".

[Jonathan Kew]

On 09/04/2019 20:44, Andrew Halberstadt wrote:
> Yeah, I did consider "non-e10s" for awhile and maybe it is the better
> choice. But here are my counter arguments:
>
> 1) One of the goals of this change is to de-clutter the treeherder UI.
> Using an 8 character symbol suffix runs counter to that goal (even if it is
> still less cluttered overall).
> 2) People who use "e10s" in their |mach try fuzzy| queries out of muscle
> memory (or in saved presets) will accidentally select the exact opposite of
> what they want.
> 3) For new contributors "e10s" is a code word anyway. It's just now they
> need to learn "fc" instead of "e10s".
>
> None of those are terribly compelling, but it's still enough to make me
> prefer "-fc".

I think (1) and (2) here are good points; I'm less convinced by (3).
Yes, e10s is a code word, but it's one that is pretty long-established
and pervasive in the project and surrounding documentation (it even
shows up in the names of about:config settings). It appeared in
treeherder UI *because* it was a well-established term within the project.

The proposed -fc suffix, on the other hand, seems gratuitously cryptic.
If it had suddenly appeared in treeherder, I'd have been totally
clueless as to its meaning; and even after seeing the announcement here,
it feels like an artificial label that's trying a bit too hard to come
up with a "clever" code where none is needed. It's not like we're
starting with a standard multi-process configuration, and launching a
grand "Fuel Cell" project that aims to merge the processes together.

How about suffixing these jobs with -sp for "Single Process"? That would
be a lot more transparent, IMO.

JK

[Andrew Halberstadt]

I had about 5 independent suggestions of "-sp" and I agree that it is much
better than "-fc". But another idea that came out of these conversations
was "1proc" which also ticks all the boxes (only being a tiny bit longer
than "e10s") and being even clearer than "-sp". I think I'll go with that
one. Thanks to everyone for all the feedback!

-Andrew

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Andrew Halberstadt]

This has now landed. So to re-iterate, if you see a "-1proc" suffix in the
task symbol that means it is running with e10s disabled. Otherwise e10s is
enabled. This symbol change will ride the trains (so you'll still see
"-e10s" on other branches for the time being).