@chad - You know how can you get more developers? Being more open to contributions :)

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 would recommend those users see Prioritization and have their business consider paying to have the feature built if it's a limitation they are faced with. We have roughly 2,600 open tasks here and 1.5 developers, Planning has more information on understanding timelines and priorities.

In T11270#207025, @chad wrote:

I can't think of a reason to prioritize this. Specifically, it seems like since Phabricator for most (all?) companies is a business critical piece of software, you'd always choose to run it on the most reliable / stable version of PHP. Is there a reason we should consider that not to be the case?

See Planning if you have questions about how we prioritize tasks.

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

I haven't explain correctly, what I mean is that this task is "Needs Triage" now but you can know how many work you will need to do (more or less) then you can set its priority (low, hight, whatever).

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 started redesigning the main header last night, don't expect it to land before stable cut this week. I'll probably land it all at once. (Header Redesign + Favorities Menu).

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.

I can't think of a reason to prioritize this. Specifically, it seems like since Phabricator for most (all?) companies is a business critical piece of software, you'd always choose to run it on the most reliable / stable version of PHP. Is there a reason we should consider that not to be the case?

Awesome! This is what I wanted!

Now that PHP 7.1 is released you could think what will need to be changed and give a priority to this task.

For what it's worth, we tried disabling the sprint-plugin but we still get the same result.

Before the menu item seem to be called Create Diff and it worked. Right now it's called Create Revision and clicking on it shows an error:

Closing for lack of feedback. You can make custom dashboard panels for whatever query / state you want to track.

Actually, I think this is a separate bug, moving to MenuItem, it's still broken there as well. Probably related to T11114

Looking forward to support PHP7

shouldAppearInCommitMessage() is marked as obsolete, but still seems necessary for me to implement a CustomField that behaves as follows:

Yep @epriestley this one looks fixed.

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 tested the patch on my install and it restores the old behaviour!

Unfortunately i'm not quite sure from exactly which version we've upgraded from. But you're probably right and it was a version before Aug 17.
I regularly read the release logs and in the ones i checked before upgrading (which was about 2-3 months worth of em) the latest Modernisation seemed the only thing touching something related to the problem.
D16413 probably didn't make it into any changelog or was just such a minor note that i didn't see it.

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.

I think this might have broken one of our Herald rules. The rule in question is an Object rule for Commits on a Project and will open an Audit whenever a commit is made to a repository that's tagged with this project.
At least it did ~2 month ago and after the upgrade it just won't fire. Just using the test console on a new commit in a repo tagged with the project simply says "Rule failed".
To make sure i already removed all the other conditions from it so it only states "always".

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.

Thanks that did it! Still working through an issue with one of our more *ahem* exotic applications, but I suspect that'll be a more involved refactor on our end.

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

I know that php7 is not supported. I mentioned that I switched php to 5 version

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: