In T221560#6727483, @RhinosF1 wrote:

Priority reflects reality not wishes. Unless anyone wants to work on this and it's high priority for them then it's inappropriate to change priority.

Is this patch going to be approved before 1.35 release?

I am actually on 1.34 now, I did not realize the original date of this task before you mentioned. I will try re-enabling the extension and seeing if the problem has resolved itself since 1.33.1

– (4aa6bfa) 02:55, September 16, 2019

is this related to ContributionScores not working on versions later than 1.33? I was digging through and found this before creating a separate task.

Something something documentation.

Here are metrics from where the master does not accept read queries, you can see where the change was made and the uneven load of read query between the two replicas

I would say core code breaking a wiki is a large priority, especially if you skip throwing the exception...it actually works as intended

@Aklapper I'm not a developer, I'm an end-user. Which is why I'm submitting a high priority breaking ticket for a core issue. The fact that it takes this long to patch is not okay, nor is your passive aggressive response in your first sentence.

Is there any update on this, @WDoranWMF ?

In T235512#5580592, @WDoranWMF wrote:

@charitwo I'm going to downgrade this from UBN.

I actually had an error related to CategoryFunctions with regard to localisation when trying to run composer and update.php but disabled the extension then I ran rebuildLocalisationCache.php just to be thorough and then tried Composer Update then update.php and both ran successfully.

The wiki is absolutely unusable with this error, it needs to be fixed immediately.

apparently there is some confusion among the denizens of wikimedia. I double checked with freenode staff just to be sure but I have not been a group contact for a very long time now!

whoops. don't know how that happened

I found a task that was created after this incident as an exact duplicate and merged it. As mentioned in the original post it was discovered on 1.32.0 (production) and is still present as of 1.33.0-rc.0 on a development install. I will be upgrading production to 1.33.0 soon but given the change log since rc.0 I do not anticipate any improvement.

the IRC account name on freenode doesn't matter, the ssh user is what must match that field

1559347684 00:08:04 [card] -!- stashbot [~stashbot@wikimedia/bot/stashbot]

I'm a complainer, not a hacker :D

surely this can be fixed after 10 years? :)

The original errors are gone, however new ones have appeared in their place:

I can redirect this channel to one more appropriate per consensus

still an ongoing issue

I am more familiar with oident but I believe either would be suitable

after speaking with a staffer today there is no issue adding an iline but the box needs to ensure an ident daemon is running for so each individual user with access has a unique identity for them or their bots. if staff see refusals they will easily up the limit for the host, but with a workaround in place they aren't likely to see such

You have no right to decline this, you are not the extension maintainer.

Yes, indeed. An all encompassing Wikimedia IRC project is the intention behind this :)

based on edit volume it should probably be flagged on meta as well