First of all, thank you very much for responding so quickly.
I saved a lot of time.
I hope everything would be a success!

I fixed it. I switched from master branch to stable

Yes. I switched from master branch to stable

I have same issue.

After updating fabricator to phorge, the above error appeared on main page. We used the latest version from master branch.

I don't see this error - can you provide reproduction instructions?

Looks great. I implemented a rough and simple logging feature over Phrequent, your extension looks more precise. I would think its better to merge/replace Phrequent rather than adding more implementations, though

I used Docker environment forked from RedpointGames. Its now migrated on a Ubuntu base and is available on a Github repository.

Could somebody please land this at some point t?

This revision is nearly impossible to test

Just a warning that I found a few bugs just by spot checking...

Well, I did ask for this to be converted into a revision, so I'm OK getting added as a reviewer. Sorry for the delay, I've been on vacation.

@tiguchi you don't have to add reviewers yourself.

That's usually a sign that the Daemons are in some trouble. Go to the Daemons app and see their status and task status.

Maybe the milestone reordering feature could be behind an opt-in toggle? Personally I don't see any problem with that and I'm also not sure why milestones have to be strictly sequential in the first place. I found myself creating milestones accidentally out of sequence and the only way to "reorder" was renaming the milestones, which felt quite punishing.

I didn't know what happened, but today email notification is working properly without any changes. {F195188}
Might be just a hiccup 😃

In D25037#1857, @avivey wrote:

I'm good with this, but we have a policy of "no landed diffs w/o tickets", so please create one before landing.

In D25054#1871, @avivey wrote:

The change should also include updating the installation instructions, and a ticket.

@Matthew the arcanist herald rule needs to be set to trigger when both conditions are met - currently even if a change is accepted only a member of Releasers can land the change because it will trigger for anyone who isn’t a member of Releasers. We want it to trigger if it both hasn’t been reviewed and the user isn’t a member of Releasers.

For completeness: The security breaches mentioned in the security guidance task are all about exposing an existing file that the attacker has new view access to; This flow is only relevant to explicitly uploading a new file, so it doesn't have the same security implications.