I'm going to switch this view to show overall commit audit status, not weird semi-viewer audit status. At one point it wasn't clear how heavily we were going to try to skew views to account for viewer status, but bucketing changes seem to have reduced the need for this and I think extending the Differential model to Audit now makes sense. See also T9430 for some context.

I'm going to merge this into T7076, which discusses revisions instead of commits/audits, but the resolution for both is likely the same and that task has a more complete discussion of context.

I don't think the task detail trivializes this. I expect PHP7 issues will take very little time to resolve, perhaps 2-3 hours? Some installs already run PHP7 with varying degrees of success, which implies there are likely few unknowns lurking in the shadows. I believe this is not a large or complex technical task; it is purely a prioritization issue.

I'll also note that this discussion is moot, anyway: this is not blocked on development resources, and is purely a prioritization issue. If we had 10 full time engineers, this still wouldn't be what any of them would be working on.

We were more open to contributions in the past. The high bar contributions now face is a direct response to the enormous maintenance burden that those changes saddled us with. This is explained in Contributing Code and elsewhere.

I believe this is probably obsoleted by D17192, or will be obsoleted by T2393.

After D17192, all commit states can be queried explicitly:

After D17192, audits bucket into a dashboard like Differential. Feedback from the Differential bucketing changes has generally been positive, so I think this is probably generally a good direction. It also improves consistency between the applications, if nothing else.

I've marked D17192 as resolving this because viewer() now means "viewer, their projects, and their packages", like Differential. exact(<user>) can be used for exactly a specific user.

I'm just going to merge this into T9640, it isn't meaningfully different from an implementation perspective and is the major compatibility issue.

We could resolve this by implementing "Responsible Users", like Differential.

I'm going to merge this into T9430 since they have the same upstream remedy. This query has largely been modern for some time, but I want to sort out T9430 before providing diffusion.commit.search.

Ah, cool. I'll throw something hacky over this for now if I have a chance, then.

I think the item didn't exist at all before, and T11114 created it as a side effect. All the installs I have immediate access to are up to date, but, e.g., neither the KDE nor WMF installs have "Create Diff" or "Create Revision" in the menu even though I have access to Differential on both.

This is 100 years old and I'm no longer sure what it's describing or how to reproduce it. Feel free to file a new issue if this is still a problem. Note that Audit is churning a lot right now (see T10978) so the behavior may change in the near term. This may also be a "viewer audit status" vs "commit overall audit status" issue in some sense (T9482 / T6024).

We no longer offer this option at HEAD. I'm moving us away from the self raise + self accept workflow to align better with Differential and because the state is unintuitive.

I believe D17183 fixes this. If you're still seeing issues after upgrading past that change, file a new issue with modern reproduction instructions.

D17183 fixes half of this: previews are now sorted in creation order, from oldest (top) to newest (bottom). This is the same order used in Differential. We use this order for previews because it makes it easier to review recently added comments while working through a review/audit.

I'm just going to presume this is resolved, in some sense, by D17181, because you can now remove auditors regardless of other outcomes.

Great, thanks for the report! This should now be fixed in HEAD of master, and promote to stable within about 72 hours.

I believe this behavior accidentally changed in D16413, on Aug 17 2016. That change caused us to use the commit's project tags instead of the repository's project tags.

If you'd like us to look at it, please file a separate bug report with reproduction instructions, following the guide in Contributing Bug Reports.

Awesome! Sorry for the churn here -- I think we have a brighter future on the other side, but have to break a few eggs to get there.

This does not describe a bug in Phabricator. See Support Resources for help understanding available support resourecs.

Okay, I saw php7.1-mysql and just wanted to make sure you were aware.

Although I earlier (in T6630#85282) felt like it was reasonable to consider separating Audit and Diffusion, there are now more existing or planned integration points and I think this approach is significantly less reasonable than the "merge them" approach. It also doesn't seem to be causing any problems on real installs.

This doesn't reproduce for me and we don't support third-party code, but it's entangled with T11114 and can stick around until I get rid of the old table.

Particularly, this does not reproduce against the upstream. All patches can be re-run in order with ./bin/storage upgrade --no-quickstart --namespace ..., and we do this somewhat regularly. This process runs cleanly:

We've formally frozen this method after D17158. The UI now encourages project.edit.

Intentional; see T12026 and T12027.

Presumably resolved by D17171?

Thanks for the report. This should be resolved at HEAD of master. Let us know if you run into anything else.

This was collateral damage from D17164.

After D17169, the clusterize command, the error message, and the documentation should be more helpful in anticipating and resolving this situation. (The documentation may take ~24 hours to actually regenerate.)

we can probably ditch that outright?

You should be able to return a list of appropriately configured PhabricatorEditEngineProfileMenuItem objects as builtins, rather than defining a new class for each application -- since "Create Task" is just "EditEngine link to the create task form", etc.

I marked D17168 as fixing this -- it just makes the replacement migration more robust, but I think that's the best we can do from the upstream. No idea how null ended up there in the first place, but I'd guess we have no way to figure it out and our lives would be no richer for knowing.

You should be able to safely update these rows to have '' instead of NULL, then continue:

Ah, sorry, I overlooked that you're using edges.

Oh -- try subclassing DifferentialCommitMessageCustomField instead of DifferentialCommitMessageField directly?

The other side of the Conduit call still issues an hg (or git, or whatever) command in most cases, but sending everything through Conduit means a different host (one which actually does have a working copy) can give us the answer if necessary.

They shouldn't interact -- T10753 is mostly about clustering. When Diffusion and the daemons need to ask questions about a Mercurial repository, they're supposed to issue a Conduit call so Phabricator can get an answer by asking another host if it needs to. In a few cases, they currently just issue an hg command, which only works if the repository is present (and up to date) on local disk.