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.

https://secure.phabricator.com/w/changelog/2021.50/

501(c)(3) is extremely easy to set up.

The fixes mentioned there would take a long time to implement, as things like strlen() are used in 900+ files.

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

In T15064#1705, @jeremy.norris wrote:

There were more upstream changes made a week ago, https://secure.phabricator.com/w/changelog/2021.49/, that included improved PHP8 compatibility...

That'll be changes for PHP 8.0 compatibility, but that's not the same as PHP 8.1 compatibility.

There were more upstream changes made a week ago, https://secure.phabricator.com/w/changelog/2021.49/, that included improved PHP8 compatibility...

In T15064#1703, @jeremy.norris wrote:

Wouldn't a massive changeset like this greatly increase difficulty of performing future merges of upstream (secure.phabricator.com)?

Wouldn't a massive changeset like this greatly increase difficulty of performing future merges of upstream (secure.phabricator.com)?

Hmm, yeah, looks to be something with how Firefox renders sites... Can confirm that reload fixes the layout.

Well, there are inconsistencies. For example, subscribers are called "spies" in the task overview, but "subscribers" in the task history, and "spies" again in task actions.

I have submitted patches to fix most of the issues. The following issues still remain.

Once the rebranding is complete we can send updated strings to translatewiki so that everything remains in sync.

(also refreshing the weirdly-rendered page once it loads corrects the problem)

What browser are you using? This has been a persistent thing for me on Firefox across multiple mobile devices. E.g., from a fresh Android 12 install on a 2340x1080 screen with "Show Desktop Site" turned off in Firefox 94.1.2: