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.

• Fixed a logic bug.
• Added passing unit tests.

So I got this mostly working locally, it's actually fairly trivial to reuse the existing token storage and infrastructure. Actually displaying the tokens might not be the most efficient of operations when there are a lot of comments on a given object. I still need to write an optimized query to fetch all of the token given in one query rather than many and then figure out how to display the tokens inline with the comments.

@littleggghost I think you might just need to run celerity to update the icons.

This is really cool!

Added documentation in D25547: Diviner: Improve documentation for remarkup code blocks

Awesome! I'm glad it finally worked. If you want all of your tasks to have the 'deadline' subtype you can edit your task form to set the subtype (or create a separate form that sets the subtype) that way you don't have to manually change the type of each task after it's created.

Did you manage to get the extension working?