Page MenuHomePhabricator
Create Task
Maniphest T271712

Require tools to host a valid toolinfo.json file (e.g. while upgrading from one Debian version to another)
Open, LowPublic
Actions

Description

Context:

I'm coming from my cluelessly created T254637: How to make https://tools.wmflabs.org/admin/tools list Author and Source Code URI for my tool?.

Problem:

Improve discoverability of source code: Reduce bus factor / risk when a maintainer is AWOL and nobody can inspect code who does not have access to the instance; allow more contributions by allowing to inspect code which is in public, hopefully end up with less cases of applying https://wikitech.wikimedia.org/wiki/Help:Toolforge/Abandoned_tool_policy etc.

Proposal:

Align a requirement for tools to provide a toolinfo.json file with the next Debian upgrade from Stretch (https://wikitech.wikimedia.org/wiki/News/Stretch_deprecation to be created some future day) to Buster (cf. Jessie to Stretch in 2019/2020 in T232677: Remove support for Debian Jessie in Cloud Services).

See https://meta.wikimedia.org/wiki/Toolhub#Publish_a_toolinfo_file_and_register_it_with_Toolhub's_web_crawler

Misc:

  • Might help define one of the checkmarks what makes a tool stable (cf. T115650: Create an authoritative and well promoted catalog of Wikimedia tools): source code is public (requirement anyway but reality can bite).
  • If we lived in a Git "filesystem" world, I'd propose a pre-commit.hook which checks for existence of a toolinfo.json file && that its field values are valid. If not, then refuse pushing. Not sure if that's socially acceptable though. And not sure what's feasible in a non-Git world where people might scp their stuff.
  • Feel free to decline if this turns out to be a bad idea and/or if you can think of better approaches.
  • Wondering if I should tag this with Toolforge-standards-committee or not.

Related Objects
Search...

Event Timeline

Aklapper created this task.Jan 11 2021, 1:15 PM
Aklapper changed the task status from Open to Stalled.
Aklapper added a subtask: T271368: UI for creating a toolinfo record.Jan 12 2021, 12:16 PM
• bd808 added a subtask: T195682: Direct tool registration.Jan 19 2021, 7:06 PM
• bd808 removed a subtask: T271368: UI for creating a toolinfo record.
• bd808 closed subtask T195682: Direct tool registration as Resolved.Apr 8 2021, 11:23 PM
Aklapper mentioned this in T282265: [Session] Finding co-maintainers for your tools.May 24 2021, 10:42 PM
• bd808 added a project: Toolhub.May 24 2021, 10:56 PM
• bd808 moved this task from Backlog to Radar on the Toolhub board.
Aklapper renamed this task from Require tools to host a valid toolinfo.json file (e.g. while moving from Debian Stretch to Debian Buster) to Require tools to host a valid toolinfo.json file (e.g. while upgrading from one Debian version to another).Mar 17 2022, 4:14 PM
Aklapper changed the task status from Stalled to Open.Jun 5 2022, 7:31 AM

I don't think this is stalled on anything. Maybe social buy-in, but not technically.

Aklapper mentioned this in T309937: API example apps on Toolforge are down with HTTP 500.Jun 5 2022, 7:33 AM
Legoktm subscribed.Jun 5 2022, 4:23 PM

I think we're better off recommending people fill out the toolinfo via striker or toolhub these days, rather than getting each maintainer to add a toolinfo.json to their tool.

Aklapper added a comment.Jun 23 2022, 8:01 AM

Right, via Toolhub that would be https://toolhub.wikimedia.org/add-or-remove-tools?tab=urls

Aklapper updated the task description. (Show Details)Jun 23 2022, 8:02 AM
Aklapper added a subtask: T311293: Set up MOTD on Toolforge for ssh'ing maintainers whose tools lack toolinfo.json.Jun 24 2022, 9:46 AM
Aklapper mentioned this in T324607: Adoption request for jarbot (jarbot, jarbot-ii, jarbot-iii) & jarallah (jarallah, jarallah-ii).Dec 7 2022, 8:03 AM
Aklapper added a comment.Dec 21 2022, 10:23 AM

See e.g. T324607 for a why.

Aklapper mentioned this in T320915: Set code repository URI when creating project tags.Sep 11 2023, 6:21 PM
Aklapper added a comment.Sep 11 2023, 6:33 PM

I'm also wondering if there is any kind of concept for validation, and if that should be a separate subtask.
Looking at current values on https://admin.toolforge.org/tools , I find code repository values like

  • become enhourly ; cd public_html/cgi or test or welcome.py or working on it
  • 404 URLs on GitHub or on hub.paws.wmcloud.org or on toolsadmin.wikimedia.org
  • empty repositories on GitHub
  • archived repositories on GitHub

See also https://wikitech.wikimedia.org/w/index.php?title=Wikitech%3ACloud_Services_Terms_of_use&diff=2080048&oldid=2080046 Section 6 requiring such data after June 2024 (T320915#9155450).

• bd808 subscribed.May 16 2025, 1:02 AM

What does "require" mean? I have a lot of naive questions about how this would be expected to benefit the Wikimedia technical community.

  • What toolinfo.json attributes would be required?
  • Is some human going to manually inspect 3570+ toolinfo files in whatever location they are required to be added?
  • Will auditing become an ongoing task for that human/group of humans?
  • What grace period would be allowed for a tool found to be non-compliant to remedy things?
  • What action will be taken when a non-compliant tool exceeds the compliance grace period?
  • What exceptions will be made for tools that are functional and widely used (for some definition of widely) but non-compliant?

I very much understand that T324607: Adoption request for jarbot (jarbot, jarbot-ii, jarbot-iii) & jarallah (jarallah, jarallah-ii) and similar events are point in time traumatic for the communities that used a given tool which breaks and then is found to be in a state that is not easily fixed. I do not necessarily conclude from that however that we should break a large number of tools all at once because someday they will probably break anyway. This and similar past suggestions of specific enforced requirements on how a tool can be built and managed usually seem to me to be barriers for the Wikimedia technical community to climb over more than anything else. As a technical volunteer why would I want to spend my time doing this work; what benefit do I get in return?

Restricted Application added a project: cloud-services-team. · View Herald TranscriptMay 16 2025, 1:02 AM
taavi triaged this task as Low priority.May 28 2025, 9:23 AM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits