library

library copied to clipboard

Participating in the Library team is the simplest of the four. Requires knowledge of submitting PRs and editing JSON in the manifests/ directory.

Tasks

• Keep plugin manifests correct and up-to-date.
• Handle issues opened by plugin developers who want to add/update their plugin.
• Seek new plugins/updates when developers don't notify us.

Workflow

Begin by checking this repo's issues for requests from plugin developers.

If someone requests an information change, simply make a commit (and send a PR if you don't yet have VCV community access) with the change to the manifests following the manifest format at https://github.com/VCVRack/community#library-team, and someone with write access will accept it after a quick review. You may combine multiple manifest updates in one PR. Do not modify or add the "status" or "latestVersion" property.

If someone requests an update to their build, leave that to the Review team (or become part of the build team by reading the instructions #353).

If someone requests a new plugin to be added, add a new JSON file to manifests/ with all known information. Do not add the "status" or "latestVersion" property.

Finally, send a pull request, and someone with write access will review and accept it. After accepted, notify the plugin developer by commenting "Updated information" in the original plugin's thread.

I think that's it, pretty simple. I may add JSON validation scripts that you should run before committing, but I'll wait until we've had a case of invalid JSON. Expecting all plugin developers to write valid JSON (like we did in during Rack 0.5) is impossible, but I can assume Library Team volunteers will do most everything correctly since you'll be more familiar with the process.

Members

• @cschol
• @phdsg

I'll use this issue https://github.com/VCVRack/community/issues/356 as a practice for someone on the Library team. Typically, each plugin developer will create an issue with the title = plugin slug (I'll personally change it if not) where they'll communicate with the Library team upon updates.

@MarcBoule has provided a scratch JSON file. Usually developers won't do that. Some things the Library team should note about this particular example:

• Remove duplicate URLs. In this case, websiteUrl should be removed since a GitHub URL is not their custom website. manualUrl should link directly to their README, if it is helpful to end users
• Status should be removed. I'll figure out what to do with that later.

DISCUSSION: Just to understand better the proposed method, is it your intention that each dev's issue, titled with his or her slug as mentionned above, remain persistent (i.e. always open), and thereby serves as the communication channel between the dev and the Library team? In this manner a request for an update of the repo's version of our plugin, for example, would be a new comment in the plugin's "issue" of that dev, instead of a new issue each time? EDIT: not sure if this is the best way to go, just brainstorming...

Yes, keep the same issue for each plugin. If the issue creator closes the issue, can they reopen it? If not, just keep it open indefinitely.

A few questions:

• Should the manifest .json files always contain all keys, e.g. contactEmail or donateUrl, even if the value is not known or used (e.g. no contact email provided or no donations)?
• Should we tag the plugin developer in the PR for updating the manifest to review?
• Do we only care here about open-source plugins and if yes, only those that have been migrated to v2 already?

• No. A blank string is an invalid URL and email address.
• Nah. You can if you want though.
• The manifests collect all plugins, even dead ones. repos/ contains only open-source ones though.

Note: Both links in initial post are non functioning 404s.

@n6smith Thanks, switched to master branch.

A few more questions:

• At this stage, developers are updating plugins without updating the version to get to final version 0.6.0. In general, can the plugin manager handle rebuilt plugins with the same version or do we have to rev the latestVersion in the manifest with every pull of new source in the submodule?
• Should the status be set to "not available" (or removed) when a plugin source code is updated (pull in submodule and PR with new SHA) until the Build Team has built the plugin or does that not matter?
• Who is responsible for setting the status key?

• An update to the build requires that the user change the version somehow, so Rack knows that an update is available. It checks oldVersion != newVersion as a criteria for requesting an update.
• I'll type something to answer these questions in the #353 issue

I've updated the first post with the WIP workflow.

case: #398 dev requested addtition. manifest was created and accepted. thread says "updated information"... is this the point where the review team picks up and creates the submodule?

The Library and Review teams can work in parallel. If you want to act on behalf of both teams, you can combine your commit as long as you follow both workflows (e.g. acknowledge that the repo has been reviewed).

The idea behind splitting these two teams is because the bar is lower for the Library team, so a PR might be made in a matter of minutes, while a review takes more effort and might take a day or two.

creators can reopen their issues unless you closed them, right? i think it'd be good to encourage devs to close their issue unless there's something to do... just for readability in the issue tracker.

@phdsg Yes, that's what the test at #393 concluded. I'm writing a better documentation for plugin developers.

@AndrewBelt do you handle the free closed-source plugins like #376 and others?

I haven't thought of a procedure for that yet.

Thanks for the help so far guys! To organize team members, state your name and I'll list your username in the first post.

Great work! I am going to catch up and mark all 238971231 GitHub notifications as read. If you need help with any specific plugin let me know.

I used to be able to add tags to issues filed, e.g. plugin, but can't anymore. @AndrewBelt Are you taking care of that?

I've disabled everyone's write access to this repo until later. Still need to make sure everything will be work properly when PRs are no longer needed.

Ah, cool. No problem.

i assume you'll handle the VCV open source entries yourself @AndrewBelt !?

@phdsg Good question. Yes, I'll handle everything for the open-source VCV plugins whenever they need an update.

@cschol @phdsg I've given you commit access so we can finally skip PRs.

If someone would like to join the Library Team, send a few correct PRs following the Workflow in the first post, and I'll also give you commit access.

i suppose

• Seek new plugins/updates when developers don't notify us.

is just to open an "invitation" at their repo and wait for them to open their channel on the community tracker?

@phdsg Sure, you can open their plugin thread for them (and "@" their username!) Although, if a volunteer is capable of researching for new plugin information and can follow the Library workflow, it's perfectly fine to bypass the plugin thread entirely. There are plenty of plugins in manifests/ without plugin threads that could use updating.

i probably won't add anybody's repo who doesn't request it. inviting unlisted devs seems to be a perfect entry level task tho.

also, could devs still close issues opened by one of the team members?

I haven't tested whether the issue OP can close an issue reopened by a collaborator, but I know that they can't reopen an issue closed by a collaborator.

I've been informed that many versions are incorrect (e.g. most of the them beginning with 0.5) on https://vcvrack.com/plugins.html for plugins not available in the build system.

So, if "status" is not "available", you are free to set "latestVersion".