Page MenuHomePhabricator

Define data models for Toolforge tool accounts and Cloud VPS projects
Closed, ResolvedPublic

Description

People can write tool metadata and descriptions in Striker. Striker was designed to replace some of the more esoteric workflows around Toolforge accounts, but as a fun bonus it also doubles as a way to write tool descriptions for Hay's Directory. As such, when you are writing a description of your tool account and its function (and crucially, its default software license), you are also writing a description for a tool. This would be just fine if tool accounts on Toolforge lined up 1:1 with actual tools that they host. This is sometimes the case, but it is very common also to have one tool account for many tools, or for no tools at all because they're test/dev/sandbox accounts. (Multi-tool accounts do have the option for adding additional toolinfo files, but I am not sure it's very intuitive.)

I am interested in more explicitly uncoupling tool accounts from the tools they describe, from a data modeling point of view. A tool account would have a very small record (name, maintainers, license), and this record would have a 1:1 or 1:many relationship with tool catalog records. This will help us as we uncouple the general concept of tools from any particular hosting provider.

Event Timeline

Based on conversation with @bd808 with at least the Toolforge half of the problem, I think for tool accounts we can go with a barebones data model as follows:

  • Tool name
  • Maintainers
  • Default license
  • Associated tools

Tool name and maintainers can be derived from LDAP directly. The only things that would require user input are associated tools and default license, but both of those things would be handled by the Striker UI.

Essentially, the result of this is that tool descriptions would be tied to the tools themselves as pieces of software, rather than any individual tool account, which would have the bare minimum data needed to (a) contact tool maintainers and (b) assert the right to fork.

We could probably use the same model for Cloud VPS projects, with project name instead of tool name. I'm also not sure how necessary a default license would be; I don't believe we currently require one on Cloud VPS.

What I wrote in the comment above is what I'm settling on, with default license optional for Cloud VPS. (To be clear, the terms of use still requires a compatible license – but as far as I can tell, we don't require Cloud VPS projects to declare a default license upfront.)