If you can hop on IRC/Conpherence in about 4 hours (around 20:00 UTC), I can try debugging this interactively.

Translatewiki finally processed the rebrand a few days ago, as part of https://phabricator.wikimedia.org/T318763

Probably this was moved?

Cool. Two things:

Is this only related to the "Authored on ..." field, as far as you can see?

(I also cannot see T15665)

Note that I cannot see Task T15663

I'm not able to find #conduit in Matrix mozilla.org homeserver btw

(It needs to be quoted just in we.phorge.it since indeed we have a Tag called Conduit :D Sorry for that)

@valerio.bozzolan If you didn't get an answer, try asking in #conduit. I didn't realize that # needs to be quoted in Remarkup. 😢

Nice! Thanks

It would be great if Mozilla's team could join forces with Phorge. Would you (the core team) contact them in #conduit on chat.mozilla.org and mozilla.slack.com?

I wonder if they are aware that Phorge exists and that we are open to contributions :)

Nevermind, this is a problem with my setup, sorry for the noise. (I missed the second line, and of course I realized it right after submitting)

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.