We're prioritizing the research to estimate how much work this is so we can possibly eventually prioritize it, so this is going into the queue, but don't read too much into it.

In T10694#174693, @jcarrillo7 wrote:

@epriestley Thats good to know. Also, will this change include formatting the Change Details section of emails? That one is currently a blob of visually unparseable text even in HTML emails.

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

(I'm just getting this into the preflight column for communication purposes since there's a slot reserved, we won't start work on this until we have an explicit confirmation.)

(If that answer isn't particularly satisfying, maybe see discussion starting here: T7820#172877.)

We haven't seen much interest in this from outside WMF, so there are probably several hundred tasks ahead of it on our natural roadmap.

Ignore my answer, I misunderstood your question. This is not expected. File a bug with reproduction instructions.

Thanks!

T10748 is moving into production, which is the last major new piece here. Remaining cleanup work I plan to do in this phase:

I think this is the current state of the world. I'm planning to tackle the three major issues noted below (observed repository versioning, repository lock granularity, device enrollment behavior) and then try to wind down this phase, move all this followup work to a new "make clustering more powerful" sort of task, and then plan where to go from there based on which goals are most important (scalability vs multi-region vs read-only vs hg/svn vs drydock vs whatever crops up as installs actually deploy this stuff).

Going any farther than this risks some inconsistency / data loss and we haven't managed to break this yet, so I'm going to consider this sufficiently robust until we see evidence otherwise.

They can link their accounts in Settings → External Accounts.

It's on an invisible page <_< >_>

This is expected. This is a security feature, not a bug. Just because you have a Phabricator user account named joe does not mean you have authority over the LDAP user account named joe, and vice versa. In many cases LDAP and Phabricator user account names differ. Users must prove they have control over external accounts by linking them before they can use those external accounts to access Phabricator.

Callsigns have been optional for a while now so I'm going to close this. See T4245 for context and followups.

Callsigns have been optional for some time (roughly since D15305 in February 2016, although there were a trickle of bugs after that).

T10748 is wrapping up, and repositories now show cluster status in the new "Storage" panel of the new UI:

I think this is substantially complete now. There will probably still be a trickle of issues as this gets more use and T10923 has some stuff that didn't get fully addressed here, but everything I've been tracking is in reasonable shape as far as I'm aware.

I think some setting like:

This was moved into the prioritization queue by a particular customer that was interested in defining Owners via Projects via external sync.

Cool -- thanks for the report, and sorry about the issue! Some of the Diffusion/repository stuff has been a little choppy lately as we've rolled out changes in connection with T10922 / T10923. Let us know if you run into anything else.

If your install is not available over http, set security.require-https in Config. This will disable the http URI.

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

This should now be fixed in HEAD of master -- try updating again? You'll need to git pull in phabricator/ to pick up the change.

This should be fixed shortly by D15876.

The problem is that a user will not read the entire email from top to bottom. There is far too much information to do that on every email that gets sent, and most of it is essentially boiler plate.

I mean that it's minor to implement -- the current plan on T9372 is "don't make any major structural changes, just adjust the existing bucketing algorithm".

I think it's a custom select field with an explicit nonempty "None" value, so display is expected.

This may have been fixed by D15507. Otherwise, we can't reproduce it, so we can't move forward. See Providing Reproduction Steps.

Awesome! Thanks for doing all the work to figure out what was going on. I'll get a diff out to apply that fix in a slightly nicer way.

This behavior seems reasonable at HEAD and we haven't seen other issues with it.

This report doesn't include reproduction steps so we can't move forward. See Contributing Bug Reports and Providing Reproduction Steps.

It sounds like this is resolved.