@klimek, heads up about these changes since I know you're a big mailing list user, too. I'll publish guidance for installs soon (likely in the "Upgrading" section of the weekly Changelog).

"Available" means "not in a meeting", which he isn't.

Looks like --background is six times faster though: https://secure.phabricator.com/xhprof/profile/PHID-FILE-zy56ub2hhqqmrsgelvdl/

I'm going to evaluate giving administrators access to the "Language" and "Email Preferences" panels if they aren't too much of a mess to implement the user/viewer split on, but I think that's all that remains here.

Is that not what this option should allow me to configure?

Here's a profile: https://secure.phabricator.com/xhprof/profile/PHID-FILE-6qploks2cyzbwune3vki/

When the option is set we'll just bypass policies when generating mail. I'll slap a giant warning on the setting and lock it down, but I think there isn't really an alternative (other than removing it, but installs might reasonably want to choose better mailing list support over policy correctness, and the policy violation is usually not large).

(It's supposed to say "Restricted Revision" instead; there's a bug for that somewhere.)

It's in closed-source (Phacility) code, and makes the "import into phacility.com" tools aware that they shouldn't try to import mailing lists.

(If "finance department" is approximately "a single human with an existing account", you can just add them to the payment account to achieve the same effect -- but they'll have total control over the instance.)

How do you currently handle this with other services? I don't recall seeing a way to CC an arbitrary address in other SAAS products, but maybe I just haven't looked carefully enough.

I rolled this into D13122.

This basically works (projects now act as lists, approximately) but we haven't seen other use cases for it.

I currently plan to convert mailing lists into users so we can policy check mail which is sent to them. That change will largely obsolete this. I'll update the "User Roles" document to explain the new behavior.

I suppose using a logged-out viewer might be fine, since we'll use the omnipotent viewer if metamta.one-mail-per-recipient is not set, and essentially all installs that use mailing lists probably have this setting configured off.

This change is potentially going to make mailing lists useless for nonpublic installs. Our immediate options are:

Not actually meaningfully stateful:

These Editors are the only ones with state properties:

Is /config/cache/ showing significant cache fullness?

The same thing applies to ArcanistDuplicateKeysInArrayXHPASTLinterRule.

Nevermind, this was some weird local issue.

OK. Apparently it also happens on this install as well.

This happens in Maniphest as well.

The user's user agent string is Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

I turned on XHPROF sampling and grabbed some data:

Sorta... My issue isn't that indexing ElasticSearch is slow, rather my issue is that queueing tasks into the daemons seems to be slow (this shouldn't be touching ElasticSearch, also I believe this issue existed when we were using MySQL indexes as well).

It might be worth noting that I am running the ./bin/search index command on the same machine that is running our daemons.

Just redirecting to the concrete ghost might be OK, too.

Awesome, thanks for testing! We'll get this upstreamed shortly.

Probably a silly question, but did you restart Apache or php-fpm after applying the patch?

At HEAD, each inline can now be individually hidden:

Tracking moves and fixes of these things seems like the hard part: it would maybe be nicer to see "all places in the codebase a task is currently mentioned", not necessarily "all places a task has ever been mentioned". But maybe this isn't actually that important.

Another (not necessarily good) attack on this would be to extract these with a linter (similar to the TODO linter), and then maybe, uh, let lint messages have an object PHID on them? I guess? This feels real sketchy but maybe there are some other reasonable things we could do which could justify it.

Can you explain what you mean in more detail? I don't know what you mean by "the report", or which application you're using, or which custom fields are working.

Pretty sure D13095 will fix this.

I think it was that phlog($ex) gives us the stack trace of the phlog() call, but if we have to pick one stack trace, the stack trace of the exception is more useful.

Having a look at this and I can't actually remember what the issue is.

Do you have a full stack trace in your error log? Usually /var/log/apache2/error_log or something like that, depending on exactly which webserver/OS you're running.

Probably a prerequisite for implementing anything like arc diviner, or whatever, too. That said, it's probably also quite a lot of work.

Diviner updates over Conduit would be awesome!

Implementing transactions. I think that this would be messy given that (currently) no user would really ever interact with Diviner, it is always the omnipotent user.

In T8352#117479, @epriestley wrote:

(There's also a uri.source in Books which should probably get an implicit value if the repository is set but uri.source is not.)

Yeah, it definitely is a weaker relationship than the current "blocking tasks" relationship. FWIW, I think that JIRA has a "related issue" field (I could be wrong, I've never actually used JIRA).

I think that's reasonable.