Just for reference, see related T15449 and Q56.

Or, additional approach could be to have a small periodic script to watch for change on diffusion.branchquery Conduit call and than to trigger a build plan through Conduit.

Would taking care of the depreciations bump the minimum PHP version required to run Phorge?

Not in itself, but we do plan to bump the minimum to 7.1 (in T15047).

Would taking care of the depreciations bump the minimum PHP version required to run Phorge?
looks good to me otherwise

@ncoker See T15586 instead

thank you @ncoker, but:

1. This is not a task to discuss specific errors when trying to run on php 8, and
2. We don't expect arcanist to work on php 8 yet

Maybe also something for this topic!
We update php yesterday on our WSL2 (Ubuntu 22.04) clients to 8.1.22 and pulled the latest arcanist from git after the commit
Now we facing this problem on starting arcanist:

D25386 and D25387 provide the big "do not crash on deprecation warning", and are probably enough to declare "experimental support for php 8.2" on their own.

In T15568#12244, @valerio.bozzolan wrote:

every extension should have its own

Ah, yeah, even better I think, if possible

every extension should have its own

In T15568#12239, @avivey wrote:

I was thinking of adding a script to ./bin to manage (mostly add/remove from load-libraries, maybe also clone) extensions.

Probably related, I think that any installed extension should not cause any touch to /src/__phutil_library_init__.php, as long as it's versioned in git in Phorge and so will cause of course merge conflicts after any update.

I was thinking of adding a script to ./bin to manage (mostly add/remove from load-libraries, maybe also clone) extensions.

I was thinking "out out", but only visible to admins - and then, only as a yellow notice at the top of the page:

This is a good plan. Would this be opt-in, e.g. this Phorge instance would be the main one with this on but other installs wouldn’t see this by default?

(Implementation notice: in both phorge and arc, this is handled in PhutilErrorHandler::handleError(), and the check is simply $num === E_DEPRECATED), and maybe E_USER_DEPRECATED.

+1

I agree that Phorge should not fall over because of a deprecation warning.

I don't think I intended to land this change.

I think we are done with the logo as we have a graphical kit.

Interestingly we are probably in a relaxed situation on certain external legal issues, but we still need to work on our internal issues such as

The primary feature is to immediately reject any support query for PHP 5.

Premising that I do not see the action plan here. What are the features that we are missing and we want to use, for example in the involved features and diffs?

I'm inclined to actually implement this, partly because (AFAIK) nobody on the team is actually running on PHP 5 to check for problems.

getLoginIcon() { return PlatformSymbols::getPlatformServerName(); } returns Phorge.
Thus no corresponding icon is found as Phorge.png does not exist and code falls back to first icon.

OK just to have a stub somewhere to start with, please feel free to edit this page:

A quick thing we can do: creating a Legalpad to accept (in a more explicit way) the terms of the Apache 2.0.

There is a blog post from Bryan Cantrill about why Node.js stopped using CLA's which might be of interest: Broadening Node.js Contributions.

A big bug we have now is the absence of a free license in the footer.

This is not triggered for {{{a}}} a or with a a {{{a}}} a, only for 1 string in front of a string with three squares.

(I think this is a sub-task of T15022)

Premising that very probably a fix there would not 100% resolve that upstream issue but surely this deserves a fix :D