Discourse got nuked, so just throwing this away until another report somehow surfaces.

Mooted by changes in T13513.

See T13513.

This stuff is largely resolved, but survived by a few remaining issues in T13290.

Owners review and auditing now have 6 and 4 options respectively, which I think cover most of the needs here. They don't handle everything (e.g. excluding merge commits) but think we're mostly in a reasonable place now and don't have any current plans to add additional shorthands.

PHI1159 would like build failures exposed to Herald to trigger audits. See also PHI953. See also PHI901.

In PHI1008, when commit X reverts commit Y, we don't write a revert edge between X and revisions associated with Y. We should.

Internally, see PHI1165 for nine pages of me complaining about this.

This doesn't seem to have caused any issues.

Okay thanks for your answer. So if i used audit.Query to get (for example) audit statuses etc.. I have to wait that diffusion.commit.search implements all functionnalities?

No.

Is it possible to unfreeze audit.query if diffusion.commit.search is not returning enough informations to replace audit.Query?

I think I didn't migrate this since there was no direct analog -- my memory's a little fuzzy, but I think the old query had some bugs / weird behaviors / general differences and there's no exact way to represent it after the change (and even if there was, the newer version -- with bucketing -- is probably way better for most users, so it's good to upgrade anyway). I figured it was better to just break it in an obvious way than subtly change it, which could be more confusing, I think.

I'm going to close this; there are two possible followups -- each of which is better focused on a more specific set of problems -- but I'm not merging it into either one since I think there's a lot of general ambiguity about problems and use cases here. If you're interested in this, feel free to follow either or both.

I'm just going to merge this into T11401, at least for the moment. That may eventually split out into application-specific tasks when it gets underway.

I may still do a bit of a UI touchup pass here but this can follow up in T10967, since there's still some other work to be done there (like purging the old double writes).

Just tested, works great. Thanks for the quick fix!

I think things should work now, let me know if you're still seeing issues. Thanks for the report!

Argh! I broke it while doing last-minute fixes to improve rendering, fix in a moment.

No prob! If it helps:

Thanks, that definitely looks like a bug.

Not sure if this is a known bug / missing feature, but FYI just in case...

This has been out in the world for a little bit without exploding. I'd like to maybe do a bit of UI touchup but that can happen after T12272.

Ah. I think you'd just see this, then:

FWIW, All packages in our monorepo have weak dominion.

Overall, you only get checkboxes for users, packages and projects which are already reviewers, with the exception that you'll get one for yourself if you aren't a reviewer yet.

How do we envision these rules applying to the following situation?

Cool, this would be great!

The general headers/sections are mostly scripted now so they should be fairly consistent, but I'm still editing the actual markup at the end of the day.

I'm good with the current balance of the changelogs - the one thing I think would be nifty is being able to accumulate the Upgrade/Compatibility sections across changelogs, for sites that aren't able to upgrade weekly. I was considering making a script to scrape that info but haven't had a chance to sit down for it. Also it'd be relying on the changelog format to be consistent (seems to be pretty darn consistent).

I think we currently get about equal amounts of "your changelogs should be more detailed" and "your changelogs have too much irrelevant stuff" feedback so I'll take that feedback under consideration but don't plan to make changes unless the overall balance of feedback shifts substantially in one direction.

We support viewerprojects() elsewhere but it isn't currently a component of the "Auditors" datasource. See also T9362#207080. I'll file a version of T9362 for the "Auditors" field.

More generally: I think your decision to not try to migrate saved queries makes a lot of sense. In lieu of that, I'd like to cast a vote for more prominent mention in the changelog. It would be great just to see a note that some queries would break and some hints on identifying and replacing/repairing the broken ones.

I've hit the same problem that @cspeckmim ran into. As best I can tell, in the new system there's no way to quite replicate the behaviour of the old 'needs' or 'problem' audit queries. The closest attempts I've come up with so far are:

• query for Audit Status = Audit Required/Needs Verification and Responsible Users = viewer(). But that includes results where the user is the diff author, not auditor.
• query for Audit Status = Audit Required/Needs Verification and Auditors = viewer(). But that misses results where user is a member of a package or project auditor.

I think this would work if I could query for Auditors = viewer()/projects(viewer())/packages(viewer()), but it seems the functions aren't composable (at least in the UI).

This is something I've wished for a few times. Along with just searching for repositories in general.

As far as "opt-in", are you mostly concerned about performance?

As far as "opt-in", are you mostly concerned about performance?

NOTE: Since packages do not own paths exclusively, any user can create a package on / of every repository and be allowed to force-accept every package review because their "everything" package is now a containing package for all other packages. However, they could already just remove the reviewers, so I don't think this is important. We could add options to Owners (e.g., an optional whitelist of "Stronger" packages) or something to prevent this, but I don't plan to do this. Just fire anyone abusing it.

Presuming this is resolved since it's extremely boring and I ran it here and on every instance in the production cluster last week without any issues, but yell if you run into problems.

This should now be resolved at HEAD of master, and should promote to stable later today.

We can only accept bug reports against current versions of Phabricator, as detailed in Contributing Bug Reports. Feel free to file a new report against a modern version, if this issue still reproduces at HEAD of master or stable.

I'm going to close this as tentatively resolved since it's fairly old and things have changed a fair bit since it was filed. I believe we may now handle this use case reasonably well. If you still have use cases for this that aren't addressed at HEAD, feel free to file a new issue describing what problems you currently face after upgrading (following Contributing Feature Requests).