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

I had experience with emails from my self-hosted mailserver not reaching Microsoft-hosted mailboxes. As far as I remember, their SMTP replies to "suspicious" mail servers with a message that includes a link to some sort of a form which the mail admin should fill out. That worked for me - might need to dig through the server logs to see the link though.

Might be worth it having the linter classes inherit from a language-specific class that would handle things like environment initialization and dependency installation.

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.

In T15071#1840, @speck wrote:

should we enable prototypes on this install to try and use the calendar application for organizing this event?

Checking the source in Arcanist repo, it seems like none of the python linters are actually configured to use an interpreter. (If I attempt to specify one for Pylint anyway, it fails with Got unexpected parameters: interpreter)

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?

4pm-8pm GMT (6-10pm GMT+2) sounds good to me - I can even go up to ~midnight and looks like I'm the east-most.

Modern(ish) linters support a separate "interpreter" config - if that's set, they run $interpreter $binary $args rather then just $binary $args. Can this be utilized?

@20after4 per commits like https://secure.phabricator.com/D9202 the changes were abandoned - there is no MediaWiki auth provider in core

@MacFan4000 the mediawiki auth is in core afaik. There is some custom stuff for the wikimedia ldap setup but the oauth part was merged upstream ages ago.

Yeah admittedly what I did was just a hack because I didn't want to implement storage and UI for a new "hidden" boolean flag.

Right now,arc lint doesn't really allow for the activation of a virtual env. That's okay when I'm just running arc lint locally, because I can just activate the environment myself and run it in that environment.

Would be a very good way to use a break during the week, and totally flexible for weekends here in that timeframe.. not sure if many are 9-5'ers Mon-Fri

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?

For Google, you can sign up for a Cloud Identity Free tenant and then set up the Oauth app inside Google Cloud. The Cloud Identity free system is basically Google Workspace/GSuite's user management system only.

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.

On Wikipedia’s phabricator instance I implemented a patch that hides the profile text on disabled accounts which helps (slightly) to disincentivize spammers.

Thanks for reporting, I've disabled the account.

Yeah if that RFC passes then that would make things way easier. And yes I used sed for a lot of the changes.

This patch suppresses the deprecation errors at each site, but there might be a simpler workaround in the same spirit: change the error_reporting calls (of which there are only a handful) to exclude E_DEPRECATED. That would risk masking any other deprecations (probably fine in production, but not in development), whereas this patch risks hiding any non-deprecation errors at these locations.

I've been think about what to do with this for a while, and I have to say, it's a hard one.

Ok, so in zulip in #general under the bridge topic that is bridged to IRC.

This is my primary jab at Packages - think of it maybe as an RFC.

Apologies for the late response, my open source work has been on the sidelines for some time.

Hey, folks -- appreciate the interest! Most of what needs doing still is outlined in T15006: Re-brand Phorge (and to a lesser extent in T15012: Update Diviner documentation to reference Phorge). There's not a ton there that's hugely difficult, there's just a lot and it's mostly tedious. Any help on anything in that list would be immensely appreciated. I have a bit more bandwidth now than I did towards the end of last year, so I can probably start making some headway on the rebrand as well now.

^ Likewise! It'd be helpful to get an update on any progress (e.g. getting this into GitHub) and on any things that need doing/things we can get involved with to help. Thanks!

We should abandon this revision as secure has already updated their pem - see https://lch.lcdevops.com/rLCARCANIST13d3a3c3b100979c34dda261fe21253e3571bc46

oh, wow. 8.1 breakage are massive - and I'm guessing more such breaking changes would creep in in next versions?

• ran arc liberate

For GitHub, they have rolled a merge queue system which is in beta: https://github.blog/changelog/2021-10-27-pull-request-merge-queue-limited-beta/ . When a pull request is approved, it is added in the queue and will be tested with all the other changes ahead in the queue which is exactly the system Zuul is using and @speck gave the link at https://zuul-ci.org/docs/zuul/latest/gating.html

Hey, is anything still going on with this? Having just discovered Phabricator I'd hate to see it die :/

Hello, does anyone have an update about when the Phorge code might be hosted on GitHub? Thank you

I've left a comment on the server-side diff.