Collecting some additional dashboard cases from stuff merged into T4144:

Packages can now be reviewers. They work very similarly to project reviewers. They can be added via the web UI or Herald. They can also be added via the CLI (by typing O123 as a reviewer or subscriber) but this isn't very convenient and I don't expect users to manually add them very often / ever.

Archived packages are no longer added as auditors to new commits after D15907 by the "Auditing Enabled" setting.

Hi @msatish! Please see Planning for help understanding planning and prioritization. Thanks!

Pretty sure D15918 is the right/expected rule: if you're an owner of "CSS" and "CSS" is set to "Auto Review: Review Changes (Blocking)", it doesn't trigger for your revisions: you don't need someone else who owns CSS to unblock your changes. Let me know if that defies expectations.

This has been slightly streamlined, modern flow is to dump first:

I mostly have T8887 working, but there's currently no way for a package to be rendered unambiguously in Reviewers: ... or Subscribers: ... from the command line in a plain text commit message, so this may be a little more involved than I'd hoped. Everything works fine until you try to interact with a revision that has package relationships, then you get into trouble:

This isn't a bug, the block has a performance-motivated explanation in a TODO comment above it:

T10940 should be resolved now, D15903 should resolve lock granularity.

I'm going to merge this into T9275, which will solve this automatically.

Moving this to "Paused" since we're waiting on feedback / deployment / bug reports / things to catch on fire.

• Patches from metamta.differential.inline-patches should be formatted more nicely in HTML mail at HEAD.
• metamta.differential.unified-comment-context has been removed and we now raise setup guidance about it.
• The View Revision button is functional locally, but waiting on design once @chad gets back from vacation next week, since my version of it looks a lot like I designed it (D15884).
• Swapping HTML mail to become the default is ready (D15885) but waiting on the button and maybe a few other designey tweaks we want to consider.
• There's an hour or so of time across all of that which I haven't tabulated yet, but I'll settle it up once those changes actually land.

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.