This task was filed through the "New Feature Request" form.
Thu, Jan 19
Wed, Jan 18
I think the big trick on this is going to be making inline comments work somewhat-correctly in the extreme case of octopus merges.
This also seems a little hard to believe to me, at least in terms of being a general flaw with this workflow:
the auditor may spend a significant amount of time before even realizing they've already looked at the changes.
You're not wrong ;). I'm mostly referring here to a scenario where a significant enough time has passed where the auditor might not remember the individual commits (months), so the list of merged commits doesn't provide too much value. The user then would have to click on each one to see if they reviewed them already, and then still try to figure out if htere are any additional changes.
As an adversarial actor, I can use the proposed rule to avoid audit of dangerous changes like this:
Tue, Jan 17
Fri, Jan 13
We are still occasionally running into this problem. A queuing system which ensures some kind of fairness would be really useful for us and others in the situation where demand is much greater than the builder resources. (A similar sentiment to T11153#180635)
Wed, Jan 11
This doesn't appear to be a feature request or bug report, so closing out. If you need support with Phabricator, please see Support Resources.
Tue, Jan 10
T12089 has a narrower description with some screenshots, I think the behavior got flipped by accident.
At least one user (and I think @epriestley also) mentioned the light highlighting of full lines is hard to distinguish / understand as full change. I'll look more into these issues before next release is cut.
Mon, Jan 9
On, one final note:
I've also made these additional changes, not directly related to the original request:
These changes are now available in HEAD of master, and should be available on stable after Jan 13. master is also safe to upgrade into right now, although some T11114 stuff may churn later this week.
Sun, Jan 8
After reviewing the state of the world in related tasks:
The *.search endpoints are preferred now, but the guidance we provide on the Conduit page could use some updating. I'll rework this a little alongside other changes here.
I'm sorry you found this interaction frustrating. How would you prefer we have handled it?
Thanks for the warm welcome to the community
It was installed from a FreeBSD package
Sorry for wasting your time. For the record:
I am currently using project.query rather than project.search. I presume the change you suggest for .search would work for query too since my recollection is that project.query also doesn't return milestones. I tried to use .search originally, but noticed that the attachments available were limited and didn't correspond to the documentation (examples mentions projects, subscribers, but then later on only watchers and members are supported) so I was scared off by the 'may change' warning:-) I can switch to using .search if that's the better thing to do - I presume you'd add attachments for the new types of information to be returned?
Fri, Jan 6
I'm going to merge this into T11580 because I think that describes what remains here.
I briefly dug these up: