Nov 25 2021
Jan 15 2021
Jan 7 2021
Nov 22 2020
Jul 19 2020
Is this patch going to be approved before 1.35 release?
Apr 27 2020
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
Apr 5 2020
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.
Mar 19 2020
Something something documentation.
Mar 8 2020
<?php # Single #require_once( 'LocalSettings.DB-single.php' ); # Replica require_once( 'LocalSettings.DB-replica2.php' );
Mar 7 2020
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
Oct 31 2019
I would say core code breaking a wiki is a large priority, especially if you skip throwing the exception...it actually works as intended
Oct 19 2019
@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.
Oct 18 2019
Is there any update on this, @WDoranWMF ?
Oct 16 2019
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.
Oct 15 2019
Oct 3 2019
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!
Aug 22 2019
Jul 7 2019
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.
Jun 1 2019
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]
Apr 22 2019
Jan 21 2019
I'm a complainer, not a hacker :D
Jan 18 2019
surely this can be fixed after 10 years? :)
Oct 24 2018
Jul 13 2018
Mar 25 2018
Feb 15 2018
Jan 16 2018
Jan 15 2018
Dec 20 2017
Dec 5 2017
The original errors are gone, however new ones have appeared in their place:
Nov 15 2017
Oct 11 2017
I can redirect this channel to one more appropriate per consensus
still an ongoing issue
Aug 24 2017
Jul 25 2017
Jul 24 2017
I am more familiar with oident but I believe either would be suitable
Jun 28 2017
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
Jun 24 2017
You have no right to decline this, you are not the extension maintainer.
Jun 1 2017
May 9 2017
May 8 2017
Yes, indeed. An all encompassing Wikimedia IRC project is the intention behind this :)