Sorry about the delay on this. I think the emails didn't go out until later and I've not had much time to dedicate to this project as expected. As of today's meeting the current plan is for @avivey to do the merge with latest updates from upstream and push, sans review.

@dcog I think the differences with the Harbormaster changes are due to the different approach taken. We planned to do the approach which you took in D25036 which re-played the Phorge diffs on top of phabricator, however in D25040 I just did a merge of the phab/master branch into phorge/master where the Harbormaster changes already existed. Since upstream didn't modify the same Harbormaster files there were no conflicts and things merged appropriately. I did a sanity check of files changed on D25005 with the files changed on D25040.

Do we even have servers to run the tests on?

I did not think we had Harbormaster set up to run unit tests - I think that involves configuring both Harbormaster and Drydock, and possibly Almanac which I don't think anyone has done.

Though it does appear additional work has been landing upstream today

Any concerns about landing those changes? Once I land I'll see about updating this instance which should make accessing the repositories possible again.

I had to skip unit tests because phabricator/phorge unit tests require a local database to test against which I don't have setup. The lint failures are either pre-existing TODO's being flagged or the newest lint which catches product name literals. We should fix the literals but I don't want to fix that as part of the merge -- would rather do that in a separate change.

Unit tests all pass. For the two lint errors, one is erroneous checking characters used in a non-code file, the other is pre-existing and fine to leave alone.

Merged the arcanist repository in D25039

It looks like upstream has issued a number of updates which we'll want to pull in. From {E4} we discussed doing the following:

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Evan recently landed a boatload of changes to address this under https://secure.phabricator.com/T13658

There is quite a bit of text that is setup like this:

pht(
  'blah blah blah %s blah blah'.
  'blah blah Phabricator blah %s'.
  'blah blah.',
  $var1,
  $var2);

A few thoughts. This sounds like a great idea as searching by article title seems a little fragile as you mention. I think a good practice for using the proposed @link would be to fully namespace it somehow like @link development.processes.i18n, though I'm not totally sure what that looks like as I'm not familiar with the Diviner format or structure. If we have the use of namespaces then managing multiple @link declarations might lead to confusion or tedious to maintain. To me this also feels more similar to something like an @id rather than @link. What are your thoughts?

A highly unfortunate side-effect of T15077: Rebrand: Tracking task is that it will invalidate a ton of translations. My guess is that upstream did not want to maintain these translations as part of the release product, possibly due to not requiring translations be part of the Phabricator release process. If we pull them into the Phorge codebase then we would likely need to update all translations for any text changes made during development, prior to release. I think it would make sense to host the translations in a repository here but I would worry about them quickly falling out of date. Handling of translations is likely a larger-sized project that we would need help managing.

As part of {E1} we reviewed this as a priority item, and have created T15077: Rebrand: Tracking task for concrete first steps forwards. There is a lot of text to update and review and that task is setup with instructions on how we're approaching it as well as listing out all the individual applications to update. Anyone interested in assisting please review that task and feel free to put your name on an application/folder, as well as ask any questions for clarification.

I put up some coding guidelines that I could recall from when I was working with upstream on example changes. I won't be back at my home office for another week so there may be some things I'm missing but I think a number of things were covered/discussed with Evan on the example changes in https://secure.phabricator.com/D21712.

Ah interesting. My own preference would be updating PhabricatoPeopleProfileController as I would associate this more as a view-level change but looking again at how this is structured I don't think it would cause any issues and I don't feel too strongly about changing it.

Real quick before landing -- should this change be made here in PhabricatorUser or would it be sufficient in PhabricatorPeopleProfileController? Placing it here affects the profile at the data model source which would likely cause the same blurb-scrub in any other location it might render, but it might also cause problems in areas which need to access the profile data for other reasons other than rendering, e.g. if a profile gets copied/cloned in memory then this might result in losing the profile data altogether. Updating only PhabricatoPeopleProfileController to call cleanupProfile() instead of within PhabricatorUser would only scrub it at the time it's being rendered (to the profile page at least).

I've only looked at the new auth frameworks briefly (WebAuthn, is there another standard too?). My basic understanding is that the browser provides the client with its own certificate which HTTP requests are able to include with it, as a means of providing authentication for the user. This seems like a reasonable thing to allow though I'd also be interested in learning more about the tech in general.

Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?

I'm having trouble landing this, I keep getting 403 errors. I suspect it's a local configuration issue, though...

Interestingly accessing /status on secure.phabricator.com seems to return a json object instead of ALIVE.

I also created a Jitsi meeting and put that in the description of {E1}.

I turned on prototypes and created {E1}, adding everyone currently (individually) cc'd on this task as an invitee.

Yeah, I think we'd like to try and update arcanist to account for this with a general solution if possible and not making updates for each individual linter which might necessitate this. There's probably some general restructuring that needs to happen to account for the same odd scenario with Java and so forth.

I think that's roughly what I ended up doing in https://secure.phabricator.com/D14632 for launching separate Java linters, where java had to be configured as the "interpreter" and checkstyle.jar (or whatever) configured as the "binary" (https://secure.phabricator.com/D15067 added the ability to pass flags to the "interpreter").

Phabricator has a Calendar application but is prototype. I believe it's mostly functional -- should we enable prototypes on this install to try and use the calendar application for organizing this event?

Based on the entries so far it seems like possible window of time for meeting would be 4pm-8pm GMT? That would mean 9am-1pm for GMT-6 and 6pm-10pm for GMT+2. If that time window seems reasonable would any day of the week be better than others?

Should this be the responsibility of the linter/tester and not part of Arcanist itself? Updating arcanist to handle the many different environment-dependent systems for languages would mean accounting for nearly every language like Javascript/npm, Ruby/rubyenv, etc. right?

That would be useful, though we might not want all disabled accounts to have their profiles description hidden for accounts disabled which aren't spam.

Thanks for reporting, I've disabled the account.

Evan just posted some comments regarding 8.1 compatibility (as well as building PHP binary to ship with Arcanist, for Mac systems at least)
https://secure.phabricator.com/T13588#256390

I just checked the emails I receive to my gmail account and noticed that the emails seem to be from the secure.phorge.dev domain. Should those be received from we.phorge.it instead? I was in the process of filling out an issue form for Microsoft and noticed this discrepancy. Could that cause issues like this?

I noticed this recently too. These PHP 8 updates have been frustrating because it breaks Arcanist for users as well...

Time tracking is an interesting topic. At my company we addressed this by having a Herald WebHook hit our internal server whenever activity we're interested in tracking happens. Our internal server tracks these activities from multiple sources (not just Phab/Phorge) and users can go in to see all their activity linked up and input the approximate time spent on those activities.

A few months back this story came up on hackernews which seems relevant. There might be things in there we can attempt to appeal to Microsoft to allow emails from this Phorge instance to go through

What mobile display are you using? From the screenshots it looks like based on the dimensions of the display phorge isn't detecting that it should render as mobile view.

I think updating the current pem file is a good holdover patch for now (sorry for the delay in reviewing the change). Re-working how arcanist manages certs is something we can look at addressing long-term.

I computed the sha256 sum of the change/updated file and verified that it matches the cert file on https://curl.se/docs/caextract.html for 2021-09-30.

Thank you for going through to make these all consistent!

Thanks for setting this up. I would like to be a group contact for the room.

Thank you for submitting this change!