I don't understand what this ticket is about then.

I used the Responsible Users field, as I'd like to see reviews that I have created, not only those for which I'm a reviewer. Bucket by Action is really nice, and filtering by Reviewer limits its usefulness (indeed, No bucketing is automatically forced).

This seems to be what you're looking for specifically?

Unfortunately this means that the "My Reviews" panel becomes unusable for people in the #reviewers group, listing nearly every revision under the Sun.

We don't currently plan to bring any more third-party linters upstream. Instead, we're going to make it easier for users to write and distribute linter bindings themselves.

In fact, this also happens with other panels. Basically the top right panel will always be duplicated to bottom left.

I have the similar problem.. Sometimes web UI shows setup issue warning "Phabricator Daemons Are Not Running". Then I restart daemons. They work fine for some period (may be a week or two). And then again "Phabricator Daemons Are Not Running" is showed...

To add another perspective, several of the above use cases also apply where non-developers are looking at code reviews as quality documents, in an audit or quality department review. Being able to easily differentiate between Change Required and Discussion\Question types of comments would make these situations easier to explain/answer -- ex:

• Explain this code review from 8 months ago where comments were made but no followup code changes were done. How did the author/reviewer know it was ready to go upstream in this situation?

Being able to show that all Change Required comments were addressed while Discussion\Question may not have been is something they can consume and move on.

i can confirm

Thanks @epriestley!

Thank you for exhaustive description. One more question:

Thanks for the attention and detailed thoughts. I really appreciate it. I
agree with your comments re standardizing the test interface. This
resolution makes sense to me.

In T8145#113258, @epriestley wrote:

Does anyone have a use case for this which isn't maintenance notifications?

You could also do this with no custom code by using Herald to trigger a Harbormaster build and having that make an HTTP request to something which runs the logic, or theoretically by using feed.http-hooks or Doorkeeper (although these are probably better after T10363).

This reproduces for me as described.

I haven't seen more segfaults since I switched.

Presuming this is resolved since we haven't received any more information in about a week.

• We'll provide a third generation differential.diff.search endpoint eventually which will be able to do this lookup in a modern, consistent way, but have no particular timeline on this.
• I'm open to accepting a patch to add 'phid' to differential.querydiffs in the meantime.
• I don't want to bring "Diff X" upstream as an object name. This (English word + space) is inconsistent with other object names, ambiguous in some contexts like CLI revision messages, surprising in other contexts like fulltext search from the global menu, and faces more internationalization issues than existing monograms.
• You can create repositories via third-generation API methods, see Diffusion User Guide: Repositories API for guidance.
• See T9766 for Herald control via API, although neither that use case nor this use case are very strong from my perspective.
• Harbormaster will get more API support eventually, but see below.

In the general (Phabricator, rather than Phacility) case we could also suppress that warning while "NUX Mode" is active, for whatever "NUX Mode" means. Presumably, it's not important to fix until you get through whatever NUX flow we end up with. This would indirectly reduce the annoyance for Phacility instances, although sync is still better.

@jmeador, this error should no longer be misleading in HEAD of master. Let us know if you run into more stuff, and thanks for the report!

I'll file something just to keep separate.

@scode, @lvital, having this level of detail on your issues before attempting T8250 is immensely helpful.

We definitely should sync it, and probably at least some other stuff, like language and pronoun, which may not be relevant now but is likely to be relevant in the future.

+1, let's revisit after T11451/T8250 and us shipping that to our users.

I'd be more comfortable just saving the description if we didn't have CustomFields. I think we do something similar in Phriction today.

So first thing I notice when starting a new test instance... Phabricator wants to set my Timezone, so OK fine, click save, get redirected to settings. Is there any means of pre-populating that before the user first logs in from admin maybe?

See also T7216, which I plan to solve primarily via T5307. This isn't too closely related, but is a somewhat-similar Dashboard configuration usability issue.

Yeah, I think we're definitely going to build T8250 before anything here or on T11451.

This discussion also doesn't really seem to define an upper bound on this feature, at least to me. If some explicit classification ("issue" vs "non-issue") is good, why isn't more better? Almost all of the arguments for this classification seem to support adding many different options ("compliment", "suggestion", "fyi", "issue", "really important issue"), perhaps multiple dimensions of classification ("serious comment", "joke intended for humans"), etc.

At least, I assume we all want to see T8250 first?

I do understand the desire to be able to more accurately frame the feedback, but I'm probably not onboard with introducing a new workflow that we need to maintain, support, and educate to all Phabricator users. I still think no real discussion can come of this until we revamp the inline / done UI. If we have a new inline/done UI, the ability for reviewers to pre-mark dones and have an option or warning when things land before they are marked done, I think from a high level that achieves the same overall goal?

wow sorry :(

In T11450#189548, @epriestley wrote:

1. The author initiates a remedy and immediately comments on the revision, like "sorry, I got interrupted and missed some of this, I'll fix it up", then promptly sends you a followup change to address the feedback.
2. The author doesn't initiate a remedy, but is apologetic and prompt in fixing things when gently prodded ("Did you miss this?") or apologetic and prompt when sent a followup revision.
3. The author doesn't initiate a remedy and is anything less than than apologetic and prompt when gently prodded (e.g., ignores a followup).

I don't think I've ever seen (3) in a professional setting. If anyone is seeing (3), this is probably not a behavior with a technical solution.

My expectation is that intent is conveyed with the plain text of the comment without requiring any real effort on the part of the reviewer, and that the use of human language allows reviewers to express a very wide range of types of feedback.

It's not optional. It's important to not confuse the fact that pressing the button is optional with the fact that a new decision has to be made with every comment.

It's not optional. It's important to not confuse the fact that pressing the button is optional with the fact that a new decision has to be made with every comment.

A few thoughts.

D16385 increases the storage length of the underlying column. Summaries will now be cut to 255 bytes or 80 display glyphs, whichever is shorter.

See D16384.

I think this is resolved as best it can be today, let me know if you still have questions.

Put another way, we're routinely asked to work around bugs in other software by applying patches to Phabricator, mostly because we're usually pretty responsive and have a short release cycle. For example, T11362 asks us to work around an unusual behavior in some GUI VCS tool, rather than asking that tool to adjust the behavior. Sometimes putting a workaround in Phabricator is reasonable, but I think that in most cases the onus should be on that other software to work correctly. If we took this to an extreme, we'd end up shouldering a huge complexity burden for bugs in other software.

(For now, I'm inclined to let this and T11450 run their courses and then talk about how we can improve meta-issues afterward. I think both of these tasks will serve as good examples of our concerns.)

In T11449#189499, @em wrote:

Is it ok for me to retitle this feature request?

Yay

Primarily, global rules bypass access control policies. They can also apply different actions.

Great and very helpful change, thank you!

This also happens with integers and epochs:

See also T9367, perhaps, where users apparently accepted changes with serious bugs because of timezone differences between remote teams, although the exact use case behind that task remains murky to me.

I will say that even if it is the same rate of honest carelessness, reducing it even by 0.5% would be very helpful in preventing massive bugs/incidents.

Responding to as much as I can. @eadler @scode feel free to chime in / correct anything below.

I don't currently have any plans to change the behavior described in T10109. At least there, I think the behavior was just confusing when testing rules, and not actually bad. My inclination is to try to find a way to make the behavior more obvious instead of changing it to resolve that confusion.

(I have no idea on this either, the related object task search is definitely fulltext.)

We truncate these summaries at 80 bytes because the underlying storage column is text80, which is only 80 bytes long when represented using binary collation in older MySQL without utf8mb4 support. We can not store more text in the general case without changing this column size.