In T15126#3158, @avivey wrote:

can we keep the actual deletion as optional for a very long time/forever, and at the same time not create the database for new installs?
that will allow installs to backup/export their logs even if they miss the deprecation warning.

I setup a cron that makes a bunch of DNS queries for different records within the phorge.it zone from all the authoritative nameservers for the zone (see T15080#1985).

Just resurfaced today (now).

The original discussion in T12144 is kinda convincing to me, although it's mostly convinces me that the term "milestone" doesn't match these objects.

can we keep the actual deletion as optional for a very long time/forever, and at the same time not create the database for new installs?
that will allow installs to backup/export their logs even if they miss the deprecation warning.

I think this should be done in two parts:

LGTM

I'm unable to reproduce this issue, after trying on multiple installs. I'm going to release this for someone else to take a try.

Looks good on my Mac. Screenshots attached.

I use Edge on Windows 11 with the browser font set to Segoe UI and it shows me that font.
The Ubuntu font is not used and looks to me terrible.

ok, I'll try. is there any expectation or format for the git message ?

also link to the updated Twitch docs about the auth API?

@k__nard: do you mind submitting the diffs as revisions using arc diff?

Looks like https://secure.phabricator.com/D21718 explicitly changed to always remove --quiet, so unless there's a new argument for it, this change is redundant.

I've ran this locally, and it looks the same to me (Chrome on Windows).

I've re-applied this patch and uploaded with arc diff, just to normalize it.

Bear with me here, because Javeline (like all js frameworks) is confusing to me.

just a small precision, when I said that I'm not sure about the return statement, I meant that it's working but I don't know if there is some need for testing for null data

@kwisatz I'll try to review the diff this week, and that will probably get to master/stable soon...

As in E14, this is really important for protecting us and contributors.

In T15026#3074, @jeremy.norris wrote:

Wouldn't it just be easier for users if the current Phacility/stable was merged into Phorge/stable, thus avoiding the need to issue git reset --hard?

In T15026#3073, @avivey wrote:

we've decided to add git reset --hard to the instructions to avoid the merges and simplify the stable issue, avoiding the merge from multiple branches.

we've decided to add git reset --hard to the instructions to avoid the merges and simplify the stable issue, avoiding the merge from multiple branches.

In T15026#3071, @jeremy.norris wrote:

Are there plans to merge the latest Phacility/stable branch into Phorge/stable branch in order to facilitate upgrades without having local merge commits being created?

Are there plans to merge the latest Phacility/stable branch into Phorge/stable branch in order to facilitate upgrades without having local merge commits being created?

release_process has been updated.

@Leon95 I encountered a merge conflict when attempting to land these changes. Could you please take a look and try to fix and land them yourself? If you need help, feel free to ping me.

I can agree to make a legalpad that is similar to the Phacility one.

I'm actually gonna close this as Resolved - we can always reopen, or refer back to this, if the issue resurfaces.

Nothing new since last time I commented here.

Thank you for your work on this, Dan!

I'll go over this to see if there's anything left to do.

@golyalpha Are you still having this issue?

Boldly closing, as L1 exists and is available to sign.