Library team about library HOT 49 CLOSED

• 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.

from library.

@n6smith Thanks, switched to master branch.

from library.

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

from library.

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

from library.

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

from library.

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.

from library.

@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.

from library.

Suggestion: Previously I requested to avoid redundancy and not include a pluginUrl if it was the same link to sourceUrl or manualUrl. Now, let's try to include a pluginUrl on as many plugins as possible, given that the URL is targeted toward users. Redundancy is fine. For example, LOGinstruments has a sourceUrl of https://github.com/leopard86/LOGinstruments, but let's now add https://github.com/leopard86/LOGinstruments/blob/master/README.md as the pluginUrl so users can quickly preview the list of modules using the same column as other plugins with separate websites.

from library.

Rack v1 will require all plugins (except Core) to supply a plugin.json file in its root. (Example at https://github.com/VCVRack/Template/blob/7c28f8d276e51d9d2c8e8de639e6823648c97e8c/plugin.json.) There are many great things we can do with this metadata. The file will be written by the plugin author rather than the Library team, so this reduces the team's responsibilities to zero, or rather transfers the responsibility to the Review team to review the metadata according to guidelines.

from library.

I'm the new maintainer of MSM and am getting ready to push 1.0.0 to the library:

• Should I use the old "MSM" issue to post a request or open a new "MSM" issue?
• Would posting the 1.0.0 overwrite/remove the 0.6.51 entry in the plugin library?

from library.

You can use the same issue. Yes, since you'll be using the MSM slug, it will overwrite the old manifest and thus the entry on the VCV Library website.

from library.

I'll use this issue #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.

from library.

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...

from library.

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.

from library.

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?

from library.

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

from library.

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?

from library.

• 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

from library.

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?

from library.

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.

from library.

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.

from library.

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

from library.

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

from library.

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?

from library.

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.

from library.

Ah, cool. No problem.

from library.

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

from library.

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

from library.

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?

from library.

@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.

from library.

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.

from library.

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

from library.

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.

from library.

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".

from library.

did a few of them...

it'd be cool to find a way to make more people participate here instead of going to places like this or on fb

from library.

@phdsg Should I make a quick post on the Facebook user group to request 2-3 more Library Team members?

from library.

We need to add this to the workflow: When a developer requests a change on their plugin's issue, a repo maintainer should open it, and then close it when the change has been satisfied. Unfortunately when a maintainer closes an issue, the OP can't reopen it, so maintainer will have to open/close all issues by watching the issues. But some additional questions:

• If I close an issue, can a maintainer reopen it?
• If I open an issue, can a maintainer close it?

Someone try reopening this issue.

from library.

works fine.

from library.

Great! When I'm at a computer I'll close all the issues that have no withstanding changes. You're welcome to get started on that before me though.

from library.

Done. Here's a handy link to all open plugin issues sorted by recently updated. This would be a good bookmark.

from library.

All of the currently open ones should probably be closed, but it wasn't immediately clear the their status is.

from library.

Stats:

• Total plugins: 137
• pluginUrl exists: 61
• no pluginUrl, but manualUrl exists: 69
• no pluginUrl, no manualUrl, potentially built from sourceUrl: 7

built from sourceUrl means: sourceUrl + "blob/<branch name>/README.md", IF README.md exists on a branch, e.g. master.

I can script the update of the manifests and push an update to the repo to set pluginUrl for all plugins. Thoughts?

from library.

It isn't necessarily true that the README is the best URL. Sometimes the github wiki, sometimes a new website was added. Sometimes the README isn't a good resource for users, so it shouldn't be the pluginUrl. Since it's only 69 without, I'd just do it on a case-by-case.

from library.

For the 69 the pluginUrl would be the manualUrl (whatever it is set to) since it exists. The remaining ones without a clear choice are only 7.

from library.

Okay, you can script whatever you need, but it would be good to review the changes afterwards.

from library.

Sounds good. I'll just do a PR.

from library.

You can commit directly.

from library.

Do you need help with the library repo ? I can help on managing github issues / do code review if you want.

from library.

Closing since this issue's purpose has been served, and the VCV Community forum is a more organized place for discussions.

from library.