This task was filed through the "New Feature Request" form.
I have a rough cut of this one.
Please use Conphernce or Ponder if you have questions about Phabricator.
Fri, Apr 21
It would be useful to extend this concept to the lifecycles of other Phabricator objects, not just Maniphest tasks. For example, people on my team have sometimes wanted to see a histogram of how long it takes Differential diffs to get reviewed, especially if we can break it down by author and/or reviewer.
Oh, you're right. I misread an implication of implementation specifics into "set", but the actual language doesn't actually suggest an implementation.
I tried to not specifically ask for a change to API or parsing, just that the missing bit I need is a base revision set on the new diff.
A maybe-less-complicated approach here could be:
@nervus70, I use satis to do this and it works fine with phabricator. You should easy be able to use https://secure.phabricator.com/api/diffusion.repository.search to generate the satis config if you have a ton of repos.
This isn't a good fit for the upstream.
You may be right, that the root problem is people putting to much content in Phriction articles. But even a need content seperation like this one
The ToC is a currently a bandaid to a design problem, that people put too much information into a single page due to lack of alternative choices. Our solution moving forward isn't to just improve the ToC, but to improve Phriction overall and allow more CMS level customization (like a permanent sidenav). Knowing why so much information is placed on a page is the root problem we're looking for. If we just improve the ToC, I don't feel we're solved the root problem.
We don't consider that to a be a root problem.
The root problem is clear: The ToC is useless in a highly hierarchical Phriction article with many nested headers.
It does include this direction (T9868), so I'm looking forward to this.
We already have a path forward on the next iteration of Phriction, and it doesn't include this direction. Please read Contributing Feature Requests and Describing Root Problems if you have future feature suggestions, root problems are required for any request filed. Thanks!
My expectation is that the workflow in the task description will generally show this:
Thu, Apr 20
Cool. Harbormaster integration will also give you other UI hints like these, to help communicate build status to reviewers so they don't accept a change which has failed or in-progress builds:
Yes, it would. We haven't fully integrated the build system with Phabricator, but I'll review the docs and see how much more work we need to do.
If you integrate with Harbormaster, users will be prompted explicitly when they try to arc land a revision with build failures:
Engineers are not hitting a prompt when landing, they are disregarding the unit test failure message or not reviewing why the build failed. Since the build failure is on an external system, the engineer needs to view this information separately (the system posts a comment why the build failed). The overall goal of a herald rule blocking the land is so that owner can communicate that checking in code without running or successful unit tests is not cool.
Can you provide some more context about why engineers are hitting the "builds failed" prompt, and continuing through it anyway with failing tests and/or nonbuilding code?
The only behavior of --lintall is to make warnings act like errors. Just raise everything at error severity to achieve the same thing without patching anything.
You are probably raising messages at "warning" severity, but want to raise them at "error" severity. See, e.g., here for a description: