Observed repositories should now version in a reasonable way.

Can you show us a screenshot of the top section of the "Members" page for the project? It should look something like this:

Bug reports must include reproduction steps. See Providing Reproduction Steps.

That last part which I just landed hasn't been vetted in production for very long yet, but I think this all works now.

D15990 removes the Lamson instructions from the documentation.

After D15989, this dialog should properly include information about tree hash and commit hash matches. It could still be more clear, but appears to at least be working as intended now.

Basically, the metadata is sufficient to generate the "Local Commits" table and little else.

The commits are not in Diffusion. Here's a real example of the metadata we store for a commit:

When you run arc diff, you provide (explicitly or implicitly) a commit range. Phabricator stores:

Prior to D15987, the easiest fix for this was to add --force:

Here and in one other report, revisions which are closed by matching a commit or tree hash with a discovered commit are not explaining this in "Explain Why". "Explain Why" is expected to be able to provide details about this:

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.