Here are the commit hash and tree hash of the commit:

Is it OK if I look at some of the data on your instance to diagnose this? I expect to look at this information:

Phabricator also does not support OpenID and we specifically declined to support it in T524#35252.

I think it may be reasonable to allow users to resign from reviews they are only indirect reviewers for, but wouldn't pursue this until after T10967.

Yeah the way that flow works is real dumb / undiscoverable / confusing / hard to use right now. It works great if you know the secret magic, but the secret magic is pretty secret.

There's some discussion of the behavior of limits in T9372#175512 / D15923.

What query is the query panel actually executing? Does it look exactly like this?

Strategy I'm pursuing (for Git) is:

You can email me directly at epriestley@phacility.com, or create a private thread in Conpherence on this install via the icon in the header.

This needs to be the default behavior. For example, if you update lib-important-security/ and the new version has a bug which causes it to fatal, Phabricator must also fatal. It is not acceptable to just skip the extension and start without loading a library that may have important security/policy code an install could rely on, because this could make the install vulnerable to security or policy threats which you expect to be protected from.

I'm going to merge this into T5267, which discusses a larger-scale effort to translate Phabricator in the relatively near term. We'll be interested in feedback like this once that's a little further along.

I'm going to merge this into T5267, which is more actionable in the short term.

I think I didn't actually do these things, I did a different and more horrible set of things and then wrote these great instructions to avoid all the msitakes I made. I'll attempt to let dump pierce through read-only, or find some other solution if that isn't straightforward.

Should be fixed in HEAD of master. Thanks for the report!

Ah! I got a repro.

I can't immediately reproduce this. Here's things running fine with mysql.host set to a bogus value:

(I marked D15981 as fixing this but I'm going to leave it open for confirmation since I'm not completely sure there weren't more cases that I missed.)

After you created the second URI, you can switch the first one to active IO back, so there the error messages does not work:

T6102 and the downstream also contain discussion of a second case which does center around exact matches -- searching for "Wikidata" -- but I can't reproduce it at HEAD:

I can't reproduce this. Here's the first repository (I/O off, disabled);

D15981 doesn't, strictly speaking, prioritize exact matches. However, it should fix the underlying issue.

I don't understand the root problem this is seeking to solve. Please read Describing Root Problems carefully and try to follow the instructions there to describe a problem we can solve.

To edit project tags for a repository, navigate to the repository main page, then click Manage Repository → Edit Basic Information and add project tags to the "Tags" field.

I don't think the behavior of the fields is unclear and we haven't seen other users run into this particular difficulty.

Unfortunately, we can't help you with this problem. We didn't write this script, do not maintain it, and have never seen it before. You should try getting in touch with the script maintainers instead. We don't have the resources to provide support for third-party code.

That seems fine to me.

Code being owned by a package does not tag it with a project.

D15977 improves some behaviors slightly and adds more extensive logging for signal handling. I don't think I caught anything with real meat to it.

D15975 should fix the (Exception) No such daemon "39084:6ra7uz"! error. I'm not sure if it will do anything for stability or not, but it should reduce noise. I didn't uncover anything interesting in resolving it (it wasn't really even a race, just a fairly straightforward set of state management bugs).

This is almost certainly not a resource problem, but I have no idea what it is.

My tentative plan here is:

I actually have no clue. There are AMIs for it in AWS but maybe that's unrelated or related in some complicated way.

(By "provide instructions to construct a similar system", I mean something we can do in a few minutes, like launch a VM in AWS. I don't see any CloudLinux 6.8 AMIs offhand there, though.)

• Do they die after 5 minutes if you start them manually?
• Can you give us access to this system, or provide instructions for us to construct a similar system? We haven't seen this on any production system we manage, but do have other installs reporting some possibly-related issues.

A sub-problem here is that if daemons discover commits but those commits are deleted before they can be processed, the tasks fail forever. This is normally unusual (git won't GC the commits for a few weeks, which often gives the daemons enough time to process them) but cases like fiddling with tracking, re-cloning a repository, everyone going on vacation for a couple weeks, or clustering an observed repository can exacerbate them.

For prioritization, I estimate we can complete this within 6 hours. It may all be straightforward and easier than that, but there are enough weird edge cases and UI implications that I don't want to commit to a best-case estimate.

Almanac Blueprints aren't mentioned downstream but I think are also a fairly good fit for this:

Yeah, I don't think this helps at all if there are 50 results, but I don't think we can do anything about that. Better solution is to fix the workflow somehow (nuance, subprojects, etc).

The original use case on the downstream task (https://phabricator.wikimedia.org/T234) was this:

I think users are probably mostly only using this UI to browse things anyway, so it's likely OK to "slow it down" a bit visually, since that could make it easier to navigate if we save users from needing to go look up information in a new window.

(Although we do formally support and have documentation for the the "import, then make hosted" and "copy the whole working directory into place" methods of repository import now, both of which skip the pre-receive rules.)

Disabling Herald there only disables the post-push, at-discovery-time rules, not the pre-push pre-receive-commit-hook rules.

My plan is to put an on-hover (always available on mobile) edit icon on top of the thumbs on the edit UI, similar to how the interaction works on workboard cards:

• We'll bring something similar to D11297 upstream.
• T6674 discusses an issue where some mime types (notably, OGG) may ambiguously be audio or video. At a minimum, we'll provide {Fxxx, layout=video} or similar to force ambiguous types to render as a specific type. This may not really be much of a problem, but if we don't have an easy, reliable way to automatically detect whether a given .ogg file has video we aren't planning to put a tremendous amount of effort into detecting it correctly at this time.