Improve comprehensibility and consistency of window placement mode names
ClosedPublic

Authored by ngraham on Aug 24 2019, 11:20 PM.

Details

Summary

Right now a few of the window placement modes suffer one or more of the following problems:

  • Inconsistency between the text shown in the Window Behavior and Window Rules KCMs
  • Title does not indicate what it does
  • Awkward wording
  • Lack of unity in grammatical mood between the different modes

This patch fixes these issues by improving the strings and standardizing on the descriptive mood:

  • Smart -> Minimal Overlapping
  • Maximizing -> Maximized
  • Cascade -> Cascaded
  • Zero-Cornered -> In Top-Left Corner

Strings are also unified between the window behavior and window rules KCMs, and docbooks are adjusted accordingly.

Test Plan


Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
ngraham created this revision.Aug 24 2019, 11:20 PM
Restricted Application added projects: KWin, Documentation. · View Herald TranscriptAug 24 2019, 11:20 PM
Restricted Application added subscribers: kde-doc-english, kwin. · View Herald Transcript
ngraham requested review of this revision.Aug 24 2019, 11:20 PM
ndavis added a subscriber: ndavis.Aug 25 2019, 1:13 AM

+1, especially changing "Smart"

Smart is such a bad name to use in general. People assume it's supposed to work the way they want it to work because that would be "Smart", instead how it actually works.

doc/windowspecific/index.docbook
340–341

Needs title style capitalization.

ngraham updated this revision to Diff 64526.Aug 25 2019, 1:29 AM

Use Title Case Where Appropriate

ngraham marked an inline comment as done.Aug 25 2019, 1:29 AM
ndavis accepted this revision.Aug 25 2019, 1:34 AM
This revision is now accepted and ready to land.Aug 25 2019, 1:34 AM
zzag added a subscriber: zzag.Aug 25 2019, 9:35 AM

Renaming "Smart" to "Avoid Overlapping"

The new name has imperative mood, which looks odd when looking at other names.

Renaming "Maximizing" to "Maximized"

"Maximizing" indicates that the placement policy maximizes clients.

"Maximized" indicates that the placement policy is maximized itself.

Take my words with a grain of salt because I hold a Ph.D degree in Broken English. I'd like to be corrected.

Renaming "Zero-Cornered" to "Top-Left Corner"

Frankly, I don't see any improvements over the old name. The old name is confusing but so is the new name.

Ensuring consistency betweeen the window behavior and window rules KCMs

More on that please.

In D23415#518506, @zzag wrote:

Renaming "Maximizing" to "Maximized"

"Maximizing" indicates that the placement policy maximizes clients.

"Maximized" indicates that the placement policy is maximized itself.

Take my words with a grain of salt because I hold a Ph.D degree in Broken English. I'd like to be corrected.

If you're looking at the words that way, you could also say that Maximizing might mean that the policy is maximizing itself, but I think it's a pretty big stretch to think it's referring to the policy rather than what is being done to the windows.

I don't think a native English speaker would be confused by the wording, but if you think non-native English speakers might get confused, that's something worth considering.

Renaming "Zero-Cornered" to "Top-Left Corner"

Frankly, I don't see any improvements over the old name. The old name is confusing but so is the new name.

For the first name to make any sense, you'd have to know that the top left is usually (0, 0) in computer graphics. That's quite technical. With the second name, you can assume that windows will appear in the top left corner. Unfortunately, that's not always the case and some apps seem to ignore the placement rules.

zzag added a comment.Aug 25 2019, 1:23 PM

I don't think a native English speaker would be confused by the wording, but if you think non-native English speakers might get confused, that's something worth considering.

Alright, let's approach this from other side. Why is "Maximized" preferred to "Maximizing?"

With the second name, you can assume that windows will appear in the top left corner.

Which one? :-) "Top-Left Corner" isn't better than "Zero-Cornered" because it's too generic imho.

zzag added a comment.Aug 25 2019, 1:30 PM

Argh, I see... We have "Zero-Cornered" and "Top-Left Corner" in window rules kcm and kwin options kcm. That's a good catch!

zzag added a comment.Aug 25 2019, 1:33 PM

I don't think that renaming smart and maximizing placement policy is worth the trouble.

In D23415#518833, @zzag wrote:

I don't think a native English speaker would be confused by the wording, but if you think non-native English speakers might get confused, that's something worth considering.

Alright, let's approach this from other side. Why is "Maximized" preferred to "Maximizing?"

I don't have anything concrete and I'm not that concerned about whether the text is Maximized, Maximizing or just Maximize because it's easy enough to figure out what it means regardless of which one you use.

With the second name, you can assume that windows will appear in the top left corner.

Which one? :-) "Top-Left Corner" isn't better than "Zero-Cornered" because it's too generic imho.

How? What else could top left corner mean? How would one have even the slightest clue what zero corner means without already being familiar with how screen coordinates work? Even the tooltip says the window is placed in the top left corner, not the zero corner.

In D23415#518850, @zzag wrote:

I don't think that renaming smart and maximizing placement policy is worth the trouble.

Even if none of the other changes are done, I think it's definitely worth renaming "Smart"

How should anyone know what that really means? How is "Smart" actually smart?

"Smart" is meaningless and must be replaced.

"Zero-cornered" is technobabble comprehensible only to KWin developers and must be replaced.

Others are judgment calls, but you're right that the moods are inconsistent (e.g. "centered" is descriptive and "cascade" imperative) and we can fix this too. Here's how they would all be in the descriptive mood:

  • Minimal Overlapping
  • Maximized
  • Cascaded
  • Centered
  • Random
  • In Top-Left Corner
  • Under Mouse

Using the imperative is much worse for the last two so I think the above is better. @zzag shall we try this?

(FWIW my wife helped me come up with these, as she's a fairly average user)

zzag added a comment.EditedAug 25 2019, 5:44 PM

I'm against renaming "smart" placement policy for couple reasons:
(a) it's been called like this since its inception, i.e. starting from late 1999
(b) "smart" is a catchy name, which is easy to memorize

How should anyone know what that really means? How is "Smart" actually smart?

I'd say if something is capable of doing taxes, then we can consider it to be "smart." However, this placement policy is called "smart" because "a really smart placement algorithm" decides how to place clients.

"Smart" is meaningless and must be replaced.

It's cool when the name of a thing precisely reflects what it is. However in this case, we'll keep the name for historical reasons.

Naming things is a can of worms. For example, "Linux" is meaningless in context of a kernel.


  • Minimal Overlapping

NACK: Leave it as "Smart"

  • Maximized

ACK: Maximizing -> Maximized

  • Cascaded

ACK: Cascade -> Cascaded

  • In Top-Left Corner

I'm tempted to use "Zero-Cornered" because that's how it's called internally. However I don't hold strong opinion on this one.

@zzag shall we try this?

Sure, just don't forget to update enums in Placement::Policy (placement.h).

ngraham updated this revision to Diff 64610.Aug 25 2019, 7:30 PM

Update strings again

ngraham edited the summary of this revision. (Show Details)Aug 25 2019, 7:33 PM
ngraham edited the test plan for this revision. (Show Details)
ngraham edited the test plan for this revision. (Show Details)

I've standardized on the descriptive mood now. But I have not reverted back to "Smart" because it's simply a bad name, and it doesn't make sense to keep it. It doesn't matter what the feature is called internally, and how long it's had that name is irrelevant if it's a bad name. And "Smart" is a bad name because unlike all the other window placement modes, it is a generic meaningless term whose name does not explain or hint at what it will do. User-visible strings are crafted for the benefit of the user, not the developer.

Also I don't think renaming the enums is a good idea:

  • If the point is to retain naming consistency throughout the codebase, then we'd need to update the strings written to and read from the config files as well, which would necessitate a kconf update script, which seems like total overkill; no other KDE project imposes such a high bar for simple string changes
  • If, to avoid the above, we just rename the enums but not all occurrences in the codebase, then we haven't actually maintained consistency, and there's no point in doing any code renaming at all
filipf accepted this revision.Aug 25 2019, 7:39 PM
filipf added a subscriber: filipf.

FWIW I didn't know what "smart" or "zero-cornered" actually meant before seeing this patch. These new strings seem more user-friendly to me.

cfeck added a subscriber: cfeck.Aug 25 2019, 11:21 PM

Is zero corner top-right on RTL systems?

ndavis added a comment.EditedAug 25 2019, 11:26 PM
In D23415#519005, @zzag wrote:

I'm against renaming "smart" placement policy for couple reasons:
(a) it's been called like this since its inception, i.e. starting from late 1999
(b) "smart" is a catchy name, which is easy to memorize

Catchiness is important if you're going to use it for marketing, but you never see KDE promoting the smart placement feature and people on forums rarely talk about it. Just because it has had a bad name since 1999, doesn't mean it should continue to be bad for another 20 years.

How should anyone know what that really means? How is "Smart" actually smart?

I'd say if something is capable of doing taxes, then we can consider it to be "smart." However, this placement policy is called "smart" because "a really smart placement algorithm" decides how to place clients.

If someone doesn't like that it usually places windows far away from where the mouse is, does that make it less smart than "Under Mouse"? No, but what makes a placement algorithm good is subjective. If a program does your taxes for you and does it correctly, then "smart" is not so subjective.

"Smart" is meaningless and must be replaced.

It's cool when the name of a thing precisely reflects what it is. However in this case, we'll keep the name for historical reasons.

Naming things is a can of worms. For example, "Linux" is meaningless in context of a kernel.

For a project, a meaningless name isn't necessarily bad. Linux only means what Linux is, which actually makes it easier to find in search engines. Features are a different matter. This is not a feature that people talk about all the time, so I don't think history is a good reason for keeping a name. Naming is pretty easy in this case: call it what it does.

New names are sound. "In Top-Left Corner" -> is it clear that we are talking about the top-left corner of the screen? Instead maybe "Top-left display corner" or "Northwest display corner"?

"In Top-Left Screen Corner?"

"Northwest" seems like kind of a funny term to use for screen geometry.

zzag requested changes to this revision.Aug 27 2019, 4:39 AM

Is zero corner top-right on RTL systems?

No, this placement policy doesn't take into account writing system.

I've standardized on the descriptive mood now. But I have not reverted back to "Smart" because it's simply a bad name, and it doesn't make sense to keep it. It doesn't matter what the feature is called internally, and how long it's had that name is irrelevant if it's a bad name. And "Smart" is a bad name because unlike all the other window placement modes, it is a generic meaningless term whose name does not explain or hint at what it will do. User-visible strings are crafted for the benefit of the user, not the developer.

Also I don't think renaming the enums is a good idea:

  • If the point is to retain naming consistency throughout the codebase, then we'd need to update the strings written to and read from the config files as well, which would necessitate a kconf update script, which seems like total overkill; no other KDE project imposes such a high bar for simple string changes
  • If, to avoid the above, we just rename the enums but not all occurrences in the codebase, then we haven't actually maintained consistency, and there's no point in doing any code renaming at all

I didn't say to touch serialized config values. I said only to adjust enum names. that's it.

Catchiness is important if you're going to use it for marketing, but you never see KDE promoting the smart placement feature and people on forums rarely talk about it. Just because it has had a bad name since 1999, doesn't mean it should continue to be bad for another 20 years.

This placement policy has been called "smart" for two decades. Many people are used to this name and I don't want to change things for old-school or current users.

I get your point about the name not being very descriptive but if you really want to make these names intuitive, then there should be some demo along the placement policy combobox in the kcm.

I don't want to discuss this topic anymore because we won't find common ground. Don't rename smart placement policy!

This revision now requires changes to proceed.Aug 27 2019, 4:39 AM
In D23415#519911, @zzag wrote:

Also I don't think renaming the enums is a good idea:

  • If the point is to retain naming consistency throughout the codebase, then we'd need to update the strings written to and read from the config files as well, which would necessitate a kconf update script, which seems like total overkill; no other KDE project imposes such a high bar for simple string changes
  • If, to avoid the above, we just rename the enums but not all occurrences in the codebase, then we haven't actually maintained consistency, and there's no point in doing any code renaming at all

I didn't say to touch serialized config values. I said only to adjust enum names. that's it.

But that doesn't make sense to me. The reason to rename it in the code as well is to preserve internal consistency with the user-displayed strings. If we only rename the enums and not the serialized values, we're not actually doing that, so what's the point?

In D23415#519911, @zzag wrote:

This placement policy has been called "smart" for two decades. Many people are used to this name and I don't want to change things for old-school or current users.

This string is buried in the Advanced tab of an infrequently-used KCM. Bad strings should be improved, even if they've been bad for 20 years. Otherwise they'll be bad for another 20 years. I really don't understand why this is controversial. No other KDE project seems imposes so high a bar on simple string changes.

In D23415#519911, @zzag wrote:

I get your point about the name not being very descriptive but if you really want to make these names intuitive, then there should be some demo along the placement policy combobox in the kcm.

That's not necessary if the names themselves are descriptive.

>And "Smart" is a bad name because unlike all the other window placement modes, it is a generic meaningless term whose name does not explain or hint at what it will do

Yes and no, it has one crucially important hint. It indicates "unless you want something special, you want this one", which the new string doesn't do.


As for the other changes, go for it.
Especially the one that brings rules and placement KCMs in sync, that's a clear bug fix.

Also I don't think renaming the enums is a good idea:

Ack. There's a separation between config keys and UI facing terms anyway for capitalisation - may as well keep it as having a separation there, and keep enums and config values in sync.

>And "Smart" is a bad name because unlike all the other window placement modes, it is a generic meaningless term whose name does not explain or hint at what it will do

Yes and no, it has one crucially important hint. It indicates "unless you want something special, you want this one", which the new string doesn't do.

I'm not sure how "smart" indicates that. Generally, "unless you want something special, you want this one" is indicated by something being the default--which Smart already is.

zzag added a comment.EditedAug 28 2019, 12:32 PM

But that doesn't make sense to me. The reason to rename it in the code as well is to preserve internal consistency with the user-displayed strings. If we only rename the enums and not the serialized values, we're not actually doing that, so what's the point?

Yes and no. My point is that enums and user visible strings should be very close, so one could have a look at the header file of Placement and see what method implements "Minimal overlapping". We can leave written config values as they are. Not great, not terrible. Just change "-ing" to "-ed" in a few places that's all what I ask.

This string is buried in the Advanced tab of an infrequently-used KCM. Bad strings should be improved, even if they've been bad for 20 years. Otherwise they'll be bad for another 20 years. I really don't understand why this is controversial. No other KDE project seems imposes so high a bar on simple string changes.

My problem is that VDG goes way overboard with user-visible strings. For example, we didn't receive any complaints about "Desktop Effects" string. Linux community settled on using that term so why do we have change it? Just to show "hey we are different!"? Same with the smart placement. I know that it received some complaints about the underlying algorithm, but not the name. I'd be happy to accept patches from VDG that fix inconsistency in KWin's kcms, e.g. missing "...", inconsistent feature names(top-left corner and zero-cornered), etc. If you want to rename a feature, please discuss that with us first by creating a task or posting to kwin mailing list rather than going the hard way (uploading a patch and having very heated discussion).

Another my problem with you VDG, which is unrelated to the change itself, is that you act a bit aggressively in code reviews. It's totally fine to have some discussion in order to change mind of code reviewers in your favor, but if you get "no" many times and the reason why maybe it's time to stop arguing. Currently I see VDG as a moving train that crashes everything in front of it.

ngraham added a comment.EditedAug 28 2019, 3:46 PM
In D23415#521038, @zzag wrote:

My problem is that VDG goes way overboard with user-visible strings. For example, we didn't receive any complaints about "Desktop Effects" string. Linux community settled on using that term so why do we have change it? Just to show "hey we are different!"? Same with the smart placement. I know that it received some complaints about the underlying algorithm, but not the name.

Martin F once gave me a very valuable piece of advice: stay within your area of expertise. This was in response to me going overboard with proposed technical changes to KWin, and it was a valid criticism. I'm not a domain expert in KWin's internals, and accordingly, I no longer propose implementation details for KWin; I leave that up to you and other KWin people. You're the experts. Once you and @davidedmundson agree on whether or not I should rename just the enums, I'll do whatever you two collectively decide.

What I am asking is for you to show me and the VDG the same courtesy when it comes to UI stuff. Trust that we're the domain experts for that, the way we trust that you're the domain experts for the technical implementation. VDG's initiatives have been extraordinarily well received among our userbase. I can't tell you how many times in the past year I have read or been told personally, "KDE is so much more polished and user-friendly then it was the last time I tried it". So I do not share your perception that VDG is an out-of-control freight train. it's true what we don't always get everything right, and you shouldn't let us run roughshod especially when the proposed implementation is wrong. But please do give us the benefit of the doubt. KDE's users are happy with the VDG.

Every other KDE project pays the VDG this courtesy--except KWin. Only in KWin do patches like this become agonizing fights that make everybody feel disrespected and exhausted. Other KDE projects look at something 20 years old as automatically suspect because it's likely missed out on two decades of improved technology and user interface polishing. Only in KWin is this inverted and the 20-year old thing is to be defended, with any change considered high risk. I can understand that attitude when you're talking about working code whose reliability is paramount, but this is a user-facing string that practically nobody has even read, and of the ones who did, none of them figured what it meant just by reading it because its name conveys no meaning. Speaking personally, this conservative attitude makes contributing to KWin intensely frustrating. I feel like I'm back in the corporate world, where every change is scary and must be justified to a committee, and any mistake gets punished. That's not how the FOSS world should be. And in general, it isn't that way for other KDE projects--just KWin.

Another my problem with you VDG, which is unrelated to the change itself, is that you act a bit aggressively in code reviews. It's totally fine to have some discussion in order to change mind of code reviewers in your favor, but if you get "no" many times and the reason why maybe it's time to stop arguing. Currently I see VDG as a moving train that crashes everything in front of it.

I see 3 VDG people (@ngraham, @filipf, and @ndavis) and one KWin person (@romangg) saying yes on renaming "Smart", and 2 KWin people (@zzag and @davidedmundson) saying no. This doesn't seem like it's a settled matter to me. And I believe I have responded to all the outstanding arguments against renaming "Smart":

  • "It's been this way for 20 years and nobody has complained" -> "it's been a bad string for 20 years, and things that are bad should be improved, regardless of how long they've been bad for"
  • "It indicates "unless you want something special, you want this one", which the new string doesn't do." -> "this is indicated by the fact that it's the default option"

So from my perspective, I'm still waiting for rebuttals, and if there are none, then that means there are no remaining legitimate objections. I understand that having these kind of back-and-forth arguments is exhausting, especially once it's gone on for days and we're all feeling defensive. But how else are we supposed to debate something controversial? If there is a better way, I'm all ears. But until then, if you're out of rebuttals, maybe that means that renaming "Smart" isn't such a bad idea after all.

alexde added a subscriber: alexde.EditedAug 28 2019, 4:54 PM

I am not sure if I am allowed to intervene in this discussion, but "smart" is a really "dumb" description as it says nothing about what it actually does.
As a user I am left to do four things to find out, what it means:

  1. Activate the option, observe the result and maybe compare it to other options
  2. Search on the web
  3. Ask someone who may know it
  4. Browse the code

That's all not necessary if it just has a meaningful name that does not need further explanations. :)

GB_2 added a subscriber: GB_2.Aug 28 2019, 4:57 PM

I am not sure if I am allowed to intervene in this discussion, but "smart" is a really "dumb" description as it says nothing about what it actually does.
As a user I am left to do four things to find out, what it means:

  1. Activate the option, observe the result and maybe compare it to other options
  2. Search on the web
  3. Ask someone who may know it
  4. Browse the code

    That's all not necessary if it just has a meaningful name that does not need further explanations. :)

Fully agree, this is what a user experiences and the reason why it should be changed.

for what its worth: to me smart means: there has been some thought put in this placement policy and it should be the best one for you. If you don't like it, you might want to try the alternatives. When I read "smart" as an option, immediately I think "that's what I want", and select it, if not already selected. In other words, it is another (better) way of saying "default", without having to go through the actual description of what it means. And then of course, I must trust the devs that "smart" is indeed smart, and is indeed what I should want, even if I don't understand it.

I'm all for keeping it like this.

hein added a subscriber: hein.EditedAug 28 2019, 7:51 PM

"Smart" is a non-label to me and pretty lazy; it's like someone did a attempt at branding an option as cool instead of putting effort into finding a succinct description of what it aims for.

The strings suggested by the patch seem like a nice improvement in clarity and making the system learnable and controllable. For as long as we pride ourselves on being "powerful when needed", that's what we should aim for - a system doing magic things you can't reason about isn't empowering.

In fact, the HIG already says that:

https://hig.kde.org/style/writing/labels.html#guidelines
Don’t shorten your labels to the point of losing meaning. A three-word label that provides clear information is better than a one-word label that is ambiguous or vague. Try to find the fewest possible words to satisfactorily convey the meaning of your label.

broulik added a subscriber: broulik.Sep 3 2019, 5:49 PM
In D23415#521420, @hein wrote:

"Smart" is a non-label to me and pretty lazy; it's like someone did a attempt at branding an option as cool instead of putting effort into finding a succinct description of what it aims for.

This. +1

ngraham updated this revision to Diff 66007.Sep 13 2019, 4:54 PM

Better rebase

GB_2 added a comment.Sep 14 2019, 7:46 AM

Is someone from KWin finally ok with this?

zzag requested changes to this revision.Sep 14 2019, 11:58 AM
In D23415#530822, @GB_2 wrote:

Is someone from KWin finally ok with this?

Nope, nothing has changed since last time.

Martin F once gave me a very valuable piece of advice: stay within your area of expertise.

I agree with that. I usually tend to look into code changes rather than UI changes. However, KWin developers have total right to veto your [VDG's] patches if you change for example the name of an effect, a script, a placement policy, etc.

In fact, the HIG already says that: ...

"Smart" is not an arbitrary string, like "left button click," etc.


Requesting changes because this patch still renames smart placement policy. The only way to proceed further from this point is to leave the name of smart placement policy as is.

This revision now requires changes to proceed.Sep 14 2019, 11:58 AM
In D23415#530984, @zzag wrote:

The only way to proceed further from this point is to leave the name of smart placement policy as is.

Wow, that's the least KDE thing I've heard this year! Totally not what I'd expect when submitting a patch to an open-source project.

FOSS development is about collaboration. No one discards your domain knowledge, feeling so worried about it seems unmotivated: in fact, from what I see, just as unmotivated as the "veto".

Luckily for both sides, changing a user-visible string to something comprehensible is not a domain knowledge of window managers. The internal implementation of 1999 seems to not be affected by this change and stays as smart (or not smart) as it is.

On a personal note, I am glad I stumbled upon this revision as I finally know now what the first setting I tweak when installing Plasma on my friends' computers actually means, and can safely remove filing a bug report against its behavior from my TODO list.

All the time I was thinking that "Smart" meaning was "place windows randomly on the screen" because I couldn't guess the logic behind. Thanks to this diff I finally know what it is really doing!

+1 for renaming UI string "Smart" -> "Minimal Overlapping"
And +1 for VDG to decide for what's best for user-visible things.

my 2c

This discussion once again consumes everyone's precious time on a minimal change. It needs to come to a conclusion.

First off UX is VDG's domain. They should of course work together with us devs on designing the best possible UX, but on the other side devs have a responsibility to value VDG's opinion and in the end execute their UX concepts (assuming that these have been produced with current best practice and knowledge of UX/UI design methodology).

Now coming to this name change: several active VDG members and Plasma devs, including native English speakers, are in favor of changing the Smart name. On KWin side Vlad is against it, I am in favor of it (mostly because the VDG is in favor of it and I don't see anything inherently wrong with the new names) and David seems to be ok with either decision.

So @zzag, is your only argument that the name was always Smart and therefore should not change or are there other arguments? Because the name just being always this way and users maybe got used to it is a very weak argument and get trumped by selecting a more descriptive naming scheme. Otherwise I propose the following:

  1. Check back on the enum/config/whatever names in the current revision. There was some indecision on how they should be. @davidedmundson: can you take a last look at these?
  2. Commit after 5.17 branch-off. This way we have till January to change the names a bit more in case we missed something and without causing several string changes on user installs.

I really like the change. I have read a bunch of the KWin code and I had no idea what "Smart" was, despite using KWin for over ten years. Simple terms and consistency are clear winners in my opinion.

The fact that multiple longtime KDE developers didn't know what the "Smart" placement mode did until they read the proposed new string in this patch is probably a better argument for it than I could ever make. :) I woudn't mind getting this in for 5.17 of course, but I could live with @romangg's proposal to delay it for 5.18 if there isn't agreement before then.

Plasma 5.17 has now branched, so we can now move forward with @romangg's plan and target this for Plasma 5.18.

@davidedmundson, can I get the final word on whether or not we should rename the enums in this patch? Yea/nay?

Just talked to David and he says it's not necessary.

romangg accepted this revision.Sep 19 2019, 4:33 PM
This revision was not accepted when it landed; it landed in state Needs Revision.Sep 19 2019, 4:35 PM
This revision was automatically updated to reflect the committed changes.