We can definitely do what GitHub does (or some reasonable approximation, at least), I just don't want to spend a lot of time implementing it without understanding what problem we're trying to solve here. I thought I understood the problem, but I think that I don't actually have a good understanding of the use cases. I'd like to step back, discuss the problem more to understand exactly what you're after and why what we have isn't working well, and then move forward from there. Specifically, what I'm trying to do is:

Github actually has an algorithm for exactly this that's mostly good.
I've thought about this feature, and would be quite satisfied if I could mark things that I've requested as 'done'

Presuming this is resolved, but let me know if that's not the case.

I can't reproduce this at HEAD, so I think you're either out of date or this was fixed recently (although I don't recall fixing it).

It seems that LINT_NAMING_CONVENTIONS doesn't work at the top level scope either.

I didn't make any other progress here.

From syslog:

I actually hit a similar issue recently when running unit tests in rPHU. I might poke around and see what comes up.

Also, to summarize the recent changes:

(In that mock, imagine that all the "reply" inlines appear in a thread, even though there's technically only one on the mock.)

In T7447#110475, @scohen wrote:

I don't know @epriestley, I found it really confusing to have my comment on a different line entirely.

We have a user_transaction table but I don't think we expose it anywhere in the UI and I'm not sure how much stuff gets dumped into it. We should record important account-related events there (creation, username changes, admin/un-admin, etc).

Is it possible that you didn't restart Apache (or PHP-FPM, if running nginx + php-fpm) and the old code is stuck in APC?

Yeah, real apps might be overkill for this.

That sounds reasonable, although a CLI script could suffice I think. ./bin/phid types for example.

Nope, sorry.

We have this; I'm not sure if it's helpful or not (not much specifically about search filters):

One of the subscribers (person A) accidentally replies-to-all with a comment. This sends two emails -- the first is from:A, to:phabricator, cc:subscribers, and the second (a few minutes later) is from:phabricator to:subscribers.

In T7447#111476, @avivey wrote:

Also, I'm missing a button to "see comment in original context", in cases where the current context is confusing.

Fold “Done” comments only. Leave “Not Done” open.

Hmm, okay. I'll take another look at this and see if I can reproduce it.

Now that PhabricatorApplicationConfigurationPanel is modular, I'm inclined to do this:

Are those processes old, from before your most recent restart? (e.g., "STARTED" column in ps auxwww) I think <defunct> usually indicates that the process is not in good shape. Maybe try this:

There's no way to limit the number of processes, no. What are the processes you're still seeing? We shouldn't generally be running the same hg log command anymore, so it would be surprising to me if you're seeing a smaller number of very similar processes.

With autoscaling pools and reduced overseer memory requirements this is probably indirectly fixed -- phd start is ~3x less memory hungry or something in that vein. Haven't seen any more reports of it recently.

Presuming this is fixed since no one's yelling, but let us know if you're still seeing issues.

They have canUseInPanelContext() now so I think this got fixed somewhere.

"Older Comment" no longer exists at HEAD. Please see T7447 for discussion of this feature.

I'm just going to kill this under the "no bug reports on prototypes" rule since I imagine we'll fix it the next time Phragment gets touched and Phragment has one trillion other problems.

I don't understand what this is asking for. You can build a panel which shows open tasks you are subscribed to like this:

Are people who have had chance to use the auto-folding inlines finding that they're an improvement?

See discussion in T7447.

I'm just going to merge this into T5955 -- this is going to become:

Hmm, I'm not sure then. It doesn't look like it's producing that much output, either ("... (10,110 more bytes) ..."), so I can't imagine it's any sort of resource exhaustion or OOM-killer kind of issue.

I'm just not sure what the expected behavior is if there are multiple valid addresses (I'd say: reject the mail, but maybe that's not what anyone else would expect).

I think we should possibly make an exception for creating objects -- for normal replies on existing objects you get two copies of basically the same mail, but for creating objects you're losing out on the link to the created object. But we're going to hit this again soon in Calendar and can take another look at it then.

Access is automatically set to require access to the containing repository if Phabricator knows about the repository (use arc which to check).

ScriptAndRegexLinter needs to be modernized, but is strictly more powerful than the proposed linter. Something like this will implement your desired lint rule after the linter modernizes:

I think it's reasonable to always let administrators disable files they can see. We don't run into any problems by supporting that and it makes cleanup a bit easier for a reasonable set of low-sophistication attacks / nuisance users (disable the user and then disable the l33t w4r3z they uploaded).

Closing for lack of feedback. See also T7674.

We don't have enough information to reproduce this problem.

T7908 is somewhat similar.

I think the HGTEST repo works now.

I think this is fixed now. In particular, the behavior today would be:

This has been in HEAD for about a month and we haven't seen any other installs reporting issues with it. If it's still causing problems, you could disable it locally like this until inbound mail gets set up:

Another possible attack on this is Phurl (T6049), a planned URL shortener application, which has the U monogram. We'll probably support named URLs (e.g., https://your.install.com/u/corp can be a named short URL which takes you to the corporate site or whatever) and we could reasonably let Phurl URLs also resolve into objects (i.e., store "the object D123" instead of "the URL http://x.y/z"). Maybe named short URLs end up with a monogram like U/corp (generically, they'd be U/8anf1X for randomly-assigned short URLs) and perhaps that covers things.

We haven't seen other requests for this and it doesn't seem very valuable to most installs. The definition of "inactive" is also subjective, and seems likely to vary from one user to another.

We haven't seen other requests for this and it doesn't seem likely to be especially valuable to very many installs. As a workaround, you could perhaps use a task or conpherence room to collect join requests instead ("comment on this task if you want to be added to project X" + link to the task in the project description).

I have a basic implementation of this in D12691 and D12692. It's really hacky, but seems to work... I'd like to iterate on this after hopefully receiving some initial feedback. I'm not exactly sure how I should proceed.

@epriestley, any advice on how to tackle this?