Sem;colon wrote:it should work without having some kind of moderator for it.
I'm sceptical that we will get someone that is checking / approving plugins in time.
As I see it there are two different actions that need to be handled:
- Add plugin to the manager.
- Pick up new versions of plugins that are already in the manager as they are released.
I agree that the most automation that can be added to this process the better. In a perfect world there would be someone reviewing every contributed plugin before it's added but that's a lot of work to expect volunteers to do in a timely manner. This would be a really big job for the initial population of the database but also ongoing as ideally each plugin version release should be checked also. A malicious actor could always make a simple benevolent 1.0.0 version of a plugin and then add the malicious code in the 1.0.1 release. Realistically I think it's best to just make sure that it's clearly stated which plugins are community contributed and add a warning that that they are to be used at your own risk. The community will have to be responsible for reporting any abuse of the system.
I do like the idea of using topics in the Plugin Support forum section to submit plugins to the manager since it builds on the current system. However, I think that will be a bit tricky to automate. It would require the plugin topics to use a fairly standardized format.
I think it would be a good idea if the plugin manager provides all released versions of the plugin, so that the user can select which version of the plugin they want to install and they are able to roll back to a previous version, rather than only having the latest version available in the manager. The reason is that new bugs or incompatibilities may be introduced in the plugin release. For example, if EG switches to Python 3 then the required changes in plugins may break backwards compatibility with older EG versions but some users may not be able to update their EG version due to using unmaintained plugins that are not compatible with the new EG version.
My closest experience with this sort of thing is the Arduino Library Manager. The way it works is the library author submits an issue
to the Arduino IDE GitHub repository issue tracker requesting their library to be added to the manager with a link to the library repository. The library has to be hosted on GitHub, it has to have the correct folder structure, it has to have a correctly formatted metadata file, and it needs to have a git tag or release for each version. One of the Arduino developers has to check the library's repository to make sure it is correctly set up, then adds the repository URL in the Library Manager database. Even though the requirements are clearly documented
, frequently there is an issue with the library repository and this requires some back and forth
between the Arduino developer and the library author to get things straightened out. So just adding each library to the manager can be a significant amount of work for the person responsible for maintaining the database with that system. It seems like the submission process could be automated so that the library author would submit the library using a form and then would get a notification if the operation failed. Whenever the author tags/releases a new version of the library it is automatically picked up by the Arduino Library Manager within an hour so that part is completely automated. The downside is that this requires the library repository to be hosted on GitHub(though it should be possible to add support for similar hosts).