User talk:BDavis (WMF)

About this board

Previous discussion was archived at User talk:BDavis (WMF)/Archive 1 on 2015-09-09.

How we will see unregistered users

1
MediaWiki message delivery (talkcontribs)

Hi!

You get this message because you are an admin on a Wikimedia wiki.

When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.

Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.

If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.

We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.

Thank you. /Johan (WMF)

18:17, 4 January 2022 (UTC)

Reply to "How we will see unregistered users"
Xover (talkcontribs)

Hey. Dropping this here because… well, because I have no clue where would be more appropriate. And the same goes for this ping: @TCipriani (WMF). On both counts: apologies for the possibly misdirected interruption. :)

Anyways… What's the story on Toolforge and the Wikimedia GitLab instance?

The context is that I recently "inherited" a tool on Toolforge where the single original maintainer is no longer active, and it's been untouched since 2015. Lot's of Python 2 -> 3, new pywikibot, cleanup of single-maintainer idiosyncrasies, general modernisation, etc. is the order of the day. And since the original code is in a personal Github repo: migrating to a new repo!

And then I get tipped off to the existence of GitLab / https://gitlab.wikimedia.org. And in my primitive "Monkey see goodie, monkey want goodie!" brain, that sounds like the best of all possible goodies: <s>no Gerrit</s>the features of Github, but integrated in the MW/WMF ecosystem (auth, not least).

But them docs… Going by the docs it looks like the WMF GitLab is both currently fully ready for production, we just need to move everyone over to it; and still in testing and we shouldn't put anything of value in it; and in some kind of early-adopter / use for personal stuff phase.

And nowhere, not in the docs not in the consultation, do I see Toolforge mentioned.

And Toolforge, to my mind, is the perfect case for this. Lots of contributors that would flat out refuse to use Gerrit no matter what incentive you gave them, can't be dictated to on such things in any meaningful way, but who we really really want to use version control somewhere we (we = the movement) have some sort of visibility and consistency. And Toolforge has lots of groupings (tools) with members (maintainers) etc., already managed through a management interface (Striker).

So when reading through GitLab/Policy I immediately think each "tool" on Toolforge should get a project (and default repo) on GitLab, either automatically or by checking a checkbox in toolsadmin. Maintainers of the tool should automatically be maintainers on the GitLab project. Toolforge should have its own namespace on GitLab, with sub-namespaces for each tool? Anyway, that sounds like it wouldn't just be sweet but even "sweeeet!", and clean up a lot of code access and revision control headaches for Toolforge.

So… Is anybody talking to somebody about Toolforge and GitLab?

Is GitLab ready for ad hoc use for Toolforge tool maintainers? And if so, how in the heck would I actually do that? Or should I just go to Github and plan to migrate later?

TCipriani (WMF) (talkcontribs)

And nowhere, not in the docs not in the consultation, do I see Toolforge mentioned.

That's an excellent point.

So… Is anybody talking to somebody about Toolforge and GitLab?

Not explicitly. We should put it on the Roadmap somewhere, even if it's at the end.

Is GitLab ready for ad hoc use for Toolforge tool maintainers? And if so, how in the heck would I actually do that? Or should I just go to Github and plan to migrate later?

The GitLab Roadmap should be up-to-date.

I would say you can use GitLab for your own personal projects, but it's going to be missing some niceties for a bit. The current thing it's missing is shared runners for CI (you can setup your own, but that's not our plan for the future). Hopefully that will be solved Soon™.

You can sign in to GitLab with a Wikimedia Developer account and use it as you would Github (with the exception of having CI which I'm aware is a big exception and hopefully very temporary).

Xover (talkcontribs)

I don't think CI is going to be too relevant for most Toolforge projects (I may be wrong). Certainly not for mine: I need a git repo with a nice web frontend for managing merge/pull requests, browsing commits, etc.; and some way to add the other maintainers for the tool (as set in Striker). My biggest concern looking at the docs was fitting those needs within the policy for namespaces etc. and whether "personal" really means personal (I'm seeing a lot of "This is my .bashrc" there), or just "not ready for mediawiki/core yet". Toolforge tools are kinda somewhere inbetween those extremes.

But in any case… A. Nyone and S. Omebody needs to start talking about just how good friends Toolforge and GitLab are going to be, and figure out who does what and when it makes sense. Unlike Gerrit->GitLab, which has some pretty significant drawbacks for at least some people, Diffusion->GitLab for Toolforge looks like all upside from where I'm sitting. A quick win, and one that helps the community more in the short term than the big migration from Gerrit. Especially if Paladox is right that the conversion on the Striker side isn't all that complicated (cf. T224676).

BDavis (WMF) (talkcontribs)

phab:T224676 is probably the correct place to discuss. My personal answer is that yes gitlab and Toolforge should be friends, and this will eventually replace the current support built into Striker (https://toolsadmin.wikimedia.org/) for creating per-tool Diffusion repositories. What I cannot say at all today is when GitLab will be "ready" to take this usage and when anyone will have the time to work on integrating Striker with GitLab.

Reply to "GitLab and Toolforge"
Izno (talkcontribs)

A "not invented here is bad" attitude is fairly unhelpful in solving technical problems. Where does one stop in a journey down the stack in the name of self-control?

When I'm compiling the assembly by hand, damnit.

Reply to "NIH"
Pavithraes (talkcontribs)
Thank you for everything you do for the Wikimedia community. You're awesome. ^>^ Pavithraes (talk) 19:39, 15 September 2020 (UTC)
BDavis (WMF) (talkcontribs)

om nom nom! I'm not likely to get real stroopwafels until we can all travel again, so I will cherish these virtual ones.

Reply to "Some stroopwafels for you!"
Summary by BDavis (WMF)

Report bugs in Magnus' tools at https://bitbucket.org/magnusmanske/

The Anome (talkcontribs)
BDavis (WMF) (talkcontribs)

Upstream bug report with Magnus is at https://bitbucket.org/magnusmanske/petscan/issues/163/petscans-down. I can only blindly restart this software, not fix any of its problems. Restarting it seems to only make things better for a few minutes or hours. Magnus needs to work on this software or recruit someone else to take it over or at least co-maintain it with him. There is really not much that I can usefully do to support the application.

Page pile tool hasn't been working for a while

2
Summary by BDavis (WMF)

Report bugs in Magnus' tools at https://bitbucket.org/magnusmanske/

ויקיג'אנקי (talkcontribs)

I'm reffering to this one. I've tried to use it from two different computers but always get this "Not Found" page. Is it just me or is this an ongoing issues that hasn't been resolved for a while? (I'm contacting you about this because the error message mentions contacting the project administrators and mentions you).

BDavis (WMF) (talkcontribs)
Jeropbrenda (talkcontribs)

Hello, I created a new tool (https://toolsadmin.wikimedia.org/tools/id/holidays-viewer) about 5 hours ago and I'm getting an error when I run become holidays-viewer. I've tried logging in and logging out several times but I'm still getting an error.

jeropbrenda@tools-sgebastion-07:~$ become holidays-viewer
become: no such tool 'holidays-viewer'
jeropbrenda@tools-sgebastion-07:~$ id
uid=21205(jeropbrenda) gid=500(wikidev) groups=500(wikidev),50380(project-tools),54127(tools.holidays-viewer)

What could be the problem?

BDavis (WMF) (talkcontribs)
Skalman (talkcontribs)

Hi, we spoke about cross-wiki gadgets at Wikimania. Krinkle showed me a way to load the whole gadget+dependencies minified. It even supports automatic RTL conversion, using the user language.

// [[File:Krinkle_RTRC.js]]
(mw.loader.getState('ext.gadget.rtrc') ? mw.loader.load('ext.gadget.rtrc') : mw.loader.load('https://www.mediawiki.org/w/load.php?modules=ext.gadget.rtrc&lang=' + mw.config.get('wgUserLanguage', 'en')));

The initial check is for loading a local version of the gadget, if such a version exists. Otherwise, it'll load the gadget from mediawiki.org.


Example taken from meta:User:Krinkle/Tools/Real-Time Recent Changes.

BDavis (WMF) (talkcontribs)
Reply to "Cross-wiki gadgets"

Following up on replication drift

8
Le Deluge (talkcontribs)

Hi Bryan Following on from our discussion a few months ago I was just wondering where we were on the new servers. I see there's been progress on Phabricator but was wondering what the timelines were looking like?

I've just had an instance where one of the zombie categories has been successfully cleared, apparently by someone creating it on enwiki and it then getting deleted. I've got my own test running on another cat but I was wondering where we go from now. Is there going to be a complete ground-zero wipe of the Labs database, or is the idea that we keep the one we have but delete operations will work? I'm in no hurry if it's a question of waiting for ground zero, but if it's the latter then I might as well get on and delete-cycle the remaining zombies on the reports I work on. Cheers. Le Deluge (talk) 12:10, 25 August 2017 (UTC)

BDavis (WMF) (talkcontribs)

The new wiki replica cluster is fully populated and ready for use by tools. Just before Wikimania we created phab:T172704 to track efforts to attract beta testers of the new servers. I'm hoping to post something to labs-announce and our phame blog soon about that, but the current phab task has all the details that should be needed for people to start using the new servers.

Le Deluge (talkcontribs)

Thanks, although I was hoping for a bit more of a phabricator-English translation, from the perspective of an occasional Quarry user. But no matter, I've been able to remove most of the zombies from my two main reports by editing or delete-cycling them, with one exception - but at least my OCD has been largely sated! [[en:Category:Law about religion in the United Kingdom]] is still stuck - it's possible that it's in a bit of the Labs db that's particularly out of sync, as it was one of a number of cats created at the same time that all had problems, but I was able to fix most of them. Any ideas about that one?

BDavis (WMF) (talkcontribs)

There is a blocker for converting Quarry to use the new database servers. The datasets_p database is not currently available on the new servers. There is yet another phab task (actually a whole pile of them) where we are trying to figure out what to do about this.

Le Deluge (talkcontribs)

No worries. As I say, the worst of my itch has now been scratched. I take it that we'll see some speed improvements once Quarry is on the new servers? The query that started working again a few months ago has been timing out for the last six weeks or so, I assumed that was a combination of the current work and kids being on holiday.

BDavis (WMF) (talkcontribs)

We do hope that the new servers will be faster. We also hope to be able to allow longer running queries to the wikireplica-analytics.eqiad.wmnet service name. That's the one that Quarry will be pointed at. The other service name is intended for tools which need quick responses.

Le Deluge (talkcontribs)

Any idea yet when Quarry moves to the new server?

BDavis (WMF) (talkcontribs)

phab:T173511 is the main blocker for converting Quarry to the new servers. The datasets_p data is currently only available on the old database servers.

Acagastya (talkcontribs)

I have sent you a mail via "Email this user".<br>Acagastya (talk) 17:42, 3 July 2017 (UTC)

Quiddity (WMF) (talkcontribs)

Sidenote: There is a user-preference (default-on) for us to get web-Notifications about any "Email from other user", so it is no longer necessary to send talkpage notes about this. :-)

Acagastya (talkcontribs)

@Quiddity (WMF): Due to a broken JavaScript gadget I was using, I could not see notifications for almost two months. It is better to leave a message, I think.

BDavis (WMF) (talkcontribs)

@AcagastyaI think I described what you need to do fairly completely in phab:T164910#3271720. The advice you have been given in #wikimedia-cloudconnect has been mixed in part because using NodeJS to write bots is not completely common and in part because you have not referenced the previous communications. What you want to do is possible. See Amir's offer to work with you in phab:T169338#3396104 for one way you might get help beyond the instructions I have already written and the documentation at wikitech:Help:Tool_Labs/Kubernetes#Kubernetes_continuous_jobs