What specific steps can I follow to reproduce this issue? See Providing Reproduction Steps for help.

See additional discussion in D9343.

I added you to Community, granting you sweeping janitorial powers on this install.

It's not 100% reliable but we can use that to make a pretty good guess.

I deployed this stuff, and I'm actually seeing more used ports now on secure001 than I did in D16389. However, I think most of these are coming from web requests and the larger count is because we have more traffic during US daytime than we did earlier in the morning. It didn't occur to me earlier that I'd be accidentally counting connections from both sources.

No problem, thanks for the report!

I think this was resolved by D16381, I just didn't deploy it until a moment ago.

How did the author/reviewer know it was ready to go upstream in this situation?

Check this out if you haven't seen it yet?

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.

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.

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!

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.

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

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.

wow sorry :(

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.

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.)

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

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.

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.

Not in the Phacility cluster today.

There's no real way to do this today, since this isn't a workflow that I think we've seen in professional environments.

In T11450#189540, @chad wrote:

Personally my only anecdote is additional controls actually slow me down.

For example, I can describe several different levels of "careless mistakes", after the author lands a revision without addressing the feedback:

I could imagine a possible future like:

Try editing it from the central administration console:

As a reviewer, I cannot distinguish between a comment I expect the author to take action on and a comment I do not expect the author to take any action on.

(Just so no one thinks too highly of me, I'll underscore that I very briefly peaked at #11. I think I had slid to about #35,000 by the end of the lightning round and "-∞ dumpster garbage rank" by the end of the competition.)

Sadly, I didn't win ICFP with PHP this year. I got up to #11 (just 33,600 points from the top slot!) but had to go to a meeting in the morning:

When you click the pencil icon next to the "Hierarchy" item, you get to a page like this one:

(I'm hoping there's no real use case for "show some other arbitrary page's navigation", although who knows.)

I'm hoping to get away with two options, e.g. a checkbox like this:

I found that the overhead of managing herald + harbormaster was much higher than our previous setup and was causing friction getting folks to adopt phabricator for new projects

Yeah -- the specific change I'd expect is basically that this:

These use the prose algorithm now, and I don't plan to try to implement syntax highlighting for prose diffs.

I think both are about 95% equivalent, my version ("a Hierarchy is a single menu item") is just easier for me to do from an engineering viewpoint and the other version I'd have to think about for a while before I could even guess how much work it is. I think the simpler-to-implement version is a bit more flexible/powerful too, although maybe not quite as intuitive at first glance.

The shortest path on the nav is probably something slightly more directly porting Profile Menu editing:

We will almost certainly never support diffs coming from multiple different repository sources. They can't be built, can't be updated, can't be patched, can't be meaningfully interdiffed, local commits are meaningless, can't be atomically landed, and they basically don't make sense in general.

Can you walk me through your workflow in more detail? The expectation is:

This is nice in theory, but I suspect it may be very complex to implement in practice.

(I've destroyed the token compromised earlier in this thread.)