I am a Release Engineer on the Wikimedia Release-Engineering-Team.
Sun, Jan 20
Wed, Jan 16
Maybe we should archive MediaWiki-extensions-Other first, then create projects for extensions on an as-needed basis.
Tue, Jan 15
Assigning this to chase since my part is mostly done. Please feel free to assign it back to me or create a subtask assigned to me if there is something more I can do to help.
I generally like the idea of compat._unicode.
Mon, Jan 7
If gerrit only shows 16x16 images, I would argue that it's not even worth doing. At that size, avatars will be difficult to distinguish and that will minimize any benefits gained by having them.
I guess this is resolved to the extent that it is possible to resolve it.
Thu, Jan 3
Dec 20 2018
Looks like the plugin has been updated?
Dec 19 2018
@EBjune: Thanks for the heads-up. I definitely want EBernhardson to weigh in. This is just exploratory work and it can wait.
Dec 15 2018
This is a really great change and I just wanted to give some props for a job well done! Thanks @BPirkle
I think one repo should be good enough for most cases. Teams could have a team specific directory inside of the repo if we wanted to organize it that way. Release engineering already has the rMREL MediaWiki Release Tools repo where we stick some random scripts but I think a cross-team repo would benefit everyone the most.
Dec 14 2018
cc'ing the rest of the releng team plus the DeviantArt cabal.
Dec 13 2018
@EBernhardson: Would it be reasonable to store this data on the search cluster? We thought to ask for your blessing to do so, in order to avoid setting up a separate elasticsearch cluster for this tiny use-case. So I guess the question is whether you think it's reasonable and won't be a burden on the Discovery-Search team.
Turns out makerelease2.py is a better way to do this, I'll write it up based on a different process than what's outlined in this task description.
Dec 12 2018
Dec 11 2018
I just updated the tarballs because I previously forgot to bump wgVersion to 1.32.0-rc.1
new tarballs created using makerelease2.py which seems to work well and it's a lot easier to use.
This would be rather complex to implement given how powerful custom policies are. The effect of a custom policy would be difficult to programmatically explain, in any kind of easily understandable prose. Is it really too difficult to go to the edit form and view the policy configuration directly?
Dec 4 2018
Nov 21 2018
thanks for the help everyone!
Nov 20 2018
Nov 17 2018
Nov 16 2018
@Andrew: Can it be done next week? I know that's pushing it given that it's a 3 day work week.
Yeah it's definitely a mysql-specific technique but it's atomic, fast and recommended in the mysql documentation.
Nov 15 2018
@Nikerabbit: It's just a temporary branch I created to give you a chance to look it over before I merge to wmf/stable ;)
Nov 14 2018
@thcipriani is going to try installing https://gerrit-review.googlesource.com/admin/repos/plugins/javamelody to hopefully collect some more useful data about the state of the JVM. At this point we are operating under the assumption that there is likely to be a new bug in gerrit 2.15 since gerrit was just upgraded yesterday. If that is the case then we need to collect more useful information to track down the cause. It's either that or cosmic rays twiddled our bits.
So the problem seems to have started between 02:00 and 02:12 UTC. There was a fairly large spike in outgoing traffic on eth0 between 02:10 and 02:12 at which point cpu load gradually falls off as a gradually increasing proportion of requests are met with 5xx errors.
phabricator sprite sheets don't support svg. It has to be png in exactly two sizes: 18x18 pixels and 36x36 pixels
As for adding them, it's done by adding to the sprite sheet in the phabricator source.
At 18px I'm not sure it's as recognizable: