In T15891#21871, @aklapper wrote:

PhabricatorSearchDocument::isInnoDBFulltextEngineAvailable() could be completely removed and this class could instead check the DB software version via mysqli::get_server_info and PDO::getAttribute(PDO::ATTR_SERVER_VERSION) ?
I guess that's a topic for a separate task though...?

I have already spent some time implementing types for a few of the widely used utility functions in rARC src/utils/utils.php (like id(), mpull(), newv(), etc..). I will make an effort to get it in shape and submit a diff for review in the near future.

@nib please do submit a diff, I'd be happy to review it.

One other thing to check: The chat uses wss (websocket) connection to communicate with aphlict. It's possible that a firewall or reverse proxy may be blocking the connection? Not all proxies support websockets in their default configuration. See verifying server status in the documentation for some tips, especially the part about load balancers and ssl.

In T15948#21505, @Cigaryno wrote:

I agree this seems pretty fundamental.

I can’t think of a reason this would be happening other than a bug or database inconsistency.

How would this work if the task has more than one revision associated with it?

There is one way to sort of do this already, by using milestones for your columns, then you can use herald 'add projects' rules. This only works by sort of abusing the purpose of milestones to take advantage of the fact that milestone columns are mutually exclusive. Adding one milestone removes the other milestones from the same parent project.

I agree that the hover behavior could be improved. Showing only after a delay could help here, though that would make it slightly worse for the times you actually want to interact with the hover.

If there are no objections I would be happy to accept the diff. @speck are your concerns addressed or should we continue discussion / consider other options?

In T15965#20144, @valerio.bozzolan wrote:

What is changing is, that unverified email will not match your unverified email as default, so that should need these 2 clicks manual configs (or, find a way to verify the email)

Another edge case: Most of my contributions to Phorge happened as part of my work for Wikimedia. Those commits are under an email address that I no longer have access to, since I am no longer employed at the Wikimedia Foundation.

Yes maniphest.edit is the modern way to do it.

Nice, it's a good step towards cleaning up this mess!

It would be nice to have some unit tests for this but that seems like it might be quite a bit of work to implement.

1. Can you add a swap file to allow memory usage above 8gb? This will have poor performance but it may allow repo processing to continue.
2. Can you tell if there is a repo which is still importing? Normal day to day repo tracking shouldn’t require tons of ram so the only situation that I can imagine needing this much ram is importing a large repository.

In T15947#19599, @avivey wrote:

Maybe express it as allowed by Policy xxx? (Related to T15277)

So essentially this:

If I were starting today I would probably design the back-end APIs first, then make the web interface derive from those APIs, such that web requests and api requests are not really any different, at least with regard to enforcing access controls.

This one seems worthy of a rubber stamp. And a gold star.

Are you importing some huge git repo or something? I haven't seen a lot of OOM with php-fpm on phorge/phabricator. It's generally not been an issue in the past so this is either a new bug or something specific to the environment. Then again, I've almost always ran Phorge with much more than 8GB of ram available.

For another example, here is a fairly straightforward use of that API which takes place entirely outside of a custom field subclass:

There is a pretty complicated and not really easy to follow subclass of ManiphestCustomField over here: https://phabricator.wikimedia.org/source/phab-extensions/browse/wmf%252Fstable/src/customfields/ReleaseDetailsCustomField.php

@keithzg what you might be missing is

$object = $this->getObject()

There is a significant amount of Phabricator dark matter out there - companies/people using the software, it works well enough, not really easy to know they exist or anything about their usage. I'm sure at least some of them have moved to Phorge. Automattic/wordpress.com have moved to Phorge and I wasn't even aware that they were using Phabricator before that. This is despite the fact that I did a pretty extensive amount of research to identify every company using Phabricator back in ~2019 as part of my work for Wikimedia, with the goal of reaching out and trying to organize an informal Phabricator users group. We had the idea that the various corporate users probably had good reasons to be collaborating and at least talking to each other since most of them were not active in the upstream project. Anyway, that never really panned out, although it did trigger a flurry of interest and some ongoing discussions via email (maybe even one video meeting but I can't remember the details now.)

I think line 392 should be:

In T15744#18236, @20after4 wrote:

I was unaware of `#0969DA` syntax from github/gitlab.

I was unaware of #0969DA syntax from github/gitlab. I'm not sure if I like that syntax better than {} but I am generally in favor of using the same syntax as other systems in order to converge towards defacto standardization.

I obviously failed to run ./bin/celerity map one more time before running arc diff.

Odd, I can't quite figure out how this would interfere with //Optional list<string>.//

I think the current syntax should be ok because it isn't normal to use {} around a project name. And my regex only matches exactly 3 or 6 hex digits, as demonstrated in the hex-color-code.txt test file.

Trusted Contributors membership granted.

Good question.

@Jack_who_built_the_house This is one of the things that always frustrated me with Wikimedia projects, there is a tendency to discourage doing something new or trying something experimental. Instead of just putting it out there and letting it either succeed or fail based on the merits, there is a lot of bureaucracy around consensus building. Sadly it's just the way things are with a community/organization as large and as socialistic as Wikimedia has become.

I think ponder is sort of a minimal viable product state currently. It lacks some features like putting questions on workboards and there just aren't many
(or any?) integrations with the rest of Phorge. That wouldn't take much effort to improve it, most likely.

Also apologies for not testing this locally in the phab ui, I was far too confident in my TDD.

man I didn't even consider that you could actually have a valid project named #0dba11 ... maybe the syntax should be something different. #{00ffff} perhaps?

It's kind of a shame that remarkup wasn't named Pharkup.

Actually add the rule to the remarkup engine.

LOL I only ever tested the unit test case. I forgot to add the rule to PhabricatorMarkupEngine:

In T15670#15501, @avivey wrote:

Thinking more, I think we'd like to allow the robots to index latest version of the code - these days the big boys know how to handle that. Stopping them from crawling older versions is still important.

Anyway, I vote to revert the change - commit pages can have discussions in.

If it's that easy, then I'm both impressed and surprised it remained this way for so long. I'm actually not quite sure I understand the reasoning for not using # to begin with.

Address review feedback:

I'll test this locally, I can't see any reason we shouldn't merge it.

This D25540: Add PhutilRemarkupHexColorCodeRule, a new remarkup rule to format color codes should be ready to merge now, if someone wouldn't mind reviewing it.

Discussed on IRC: it seems that this should have been POST all along.

In D25540#16124, @valerio.bozzolan wrote:

About your Remarkup unit tests, try to rebase. Maybe related to D25559.