GitHub returns no results as well, which aligns with my expectation. Do you have an example piece of software that does work like this?

Somewhat related to T4706.

In T10308#158036, @epriestley wrote:

I think I could just build this as an extension? (I've never built one, so I'm a little interested in building one for practice)

Yes:

Thank you :)

See Planning for more information on understanding timelines and priorities, which also answers your question. Thanks!

Speaking of which, was there any progress on this? Debian release is very close, and I have to make phabricator package uninstallable (keeping only Arcanist and libphutil in).

In T9640#189032, @michaeljs1990 wrote:

@reet- If you are using ppa:ondrej/php they tend to be of higher quality then the official php packages maintained on ubuntus ppa in most cases. You have to trust someone however and in this case it's ondrej instead of canonical.

My webserver is apache, first i have same problem, when i disable SELinux, i clone the repo, 500 error is gone, but always "not found"……

I think we'd have to build another Remarkup rendering target to accomplish that (sending sanitized text-only emails, for example). I also believe we do no policy checks in Remarkup (which is cached).

In T11085#178406, @epriestley wrote:

You're watching #twitter.

libcurl supports SMTP (see https://curl.haxx.se/libcurl/c/smtp-mail.html) and can be used instead, provided that the relevant functions are exposed to PHP. This avoids needing to shell out to an external executable.

That would help me a bit though ;)

I think the desired behavior is to silently drop the notifications, yes. Specifically, they should be dropped in PhabricatorMailReplyHandler->filterRecipientUsers().

No clue how to reproduce this.

This recently got rewritten in connection with T11114 and I didn't come up with a way to reproduce it. Not sure if it's still an issue, but we need better reproduction steps if it is.

This is older than time itself and does not meet the modern standards for a feature request. In particular, I have no idea what problem it was intended to resolve and nothing that has been linked here in the last couple of years gives me much of an idea. There are likely better approaches in a modern context (T5873, T3875 + T11355, maybe?). If you want this for some purpose, feel free to file a new request describing your problem in better detail. T11355 is probably the most relevant?

I can't reproduce this at HEAD. I suspect D14853 resolved it.

T11114 has fixed the web-originated-edit versions of this, where your "Edit Revision" or "Change Reviewers" action spans another edit.

Isn't the right answer to make the web interface reject things that would choke the parser?

The underlying issue here is that fields may, in the general case, contain multiple paragraphs, colons, things that look like field headers, and may be line-wrapped. We must parse this as two fields:

T9235: Add a warning about "always_populate_raw_post_data" being misconfigured is irrelevant on php7, as the setting has been removed. Trying to set it in php.ini appears to silently do nothing.

In T10038#150670, @epriestley wrote:

Do you see there being a "Blessed" foo-linter (maybe as a repo on this instance?), or will there be multiple foo-tributes fending themselves in the wilds of github?

This is all still pretty early, but I imagine this instance mostly just collecting packages into a directory for now. The actual source might be on GitHub, but you'd be able to search this instance to find all foo-linter extensions by authors who had bothered to register their packages.

In some cases, we'd likely pull linters out of arc and turn them into Phacility-Published extensions (secure.phabricator.com/phacility/foo-linter) which we'd sign. These would be "blessed", as long as you continue trusting our signing keys.

In some cases, I'd like to "soft-bless" extensions as "safe, but don't come to us for support" with some sort of "Community Badge of Quality" key. For example, you might publish a secure.phabricator.com/cburroughs/foo-linter) which we'd sign in an advisory way which mean "we looked at the code, it seems fine, but we aren't taking bug reports for it". The UI and arc install would show users that someone they trust also trusts this code.

In some cases, untamed wilds, but collected in one place and searchable, with signing and a consistent toolset.

If nothing is blessed, you may have to make a decision like this yourself:

$ arc install foo-lint
Query "foo-lint" matches multiple packages:

  secure.phabricator.com/alice/foo-lint
  secure.phabricator.com/bob/foo-lint

None of these packages or vendors are signed by anything you trust.

Which package do you want to install?

But I think that should be OK. And we can do some level of positive and negative curation (advisory signing on good packages, disabling bad packages)..

You'll also be able to have an internal package directory for your company's stuff, so you can just publish internal things to it and then everyone can use standard tools to manage extensions.

Some day far in the future I could imagine the package directory integrating with other applications (e.g., giving each package its own repositories and tasks, like GitHub) but that's definitely far in the future. I expect most extensions (like linter bindings) to be small so they wouldn't get much benefit (e.g., 100 lines of code updated a couple times a year) and large extensions (eventually, third-party applications) to probably want to self-host on their own Phabricator instances in most cases.

The immediate goal is just fixing the problem that distributing extensions is a huge pain and all solutions have major downsides, with "convince the upstream to accept the extension" being the best option for everyone but us. The new distribution mechanism would be:

$ arc lint
Okay, automatically installing all the extensions this project needs.

(...prompts if you need to trust new stuff...)

Done!
...
nice lint output

Which fixes distribution. In the long run, there's a lot we can do to build stronger ecosystem tools, but I'm less worried about tackling that stuff today than I am about moving distribution to a broadly reasonable mechanism.

I'm going to dump everything into master now because I believe any disastrous brokenness should be reasonably easy to fix at this point.

Maybe similar to T10312 as well... If we see a test plan, skip the next one?

Expected, though it's going to take me a while to find the dupe.

We still require steps to reproduce and version information on bug reports. See Contributing Bug Reports for more details.