Create Task
Maniphest T13377

Draft of Python plugins acceptance policy
Open, NormalPublic
Actions

Description

It was based on a meeting July 6th, 2020.

Conditions for a plugin:

  • promise of maintenance
  • generally useful (not a niche feature) or lots of users (based on KA/github activitity -> that proves usefulness)
  • needs to be checked for security
  • not absolutely terrible code quality
  • needs to be licensed appropriately: the license must be GPL-compatible. It can be GPL, MIT or CC-0 for example. (For custom license we'd need to ask KDE lawyers first)
  • [suggestion to follow Blender's rules] commercial plugins only accepted from sponsors? (but still licensed appropriately)
  • ???

Not accepted plugins:

  • share.krita.org
    • maybe we should decommission? There is some weird stuff happening there, well, not weird, it's just a part of some bigger website (pling.com) that asks for financial support and lets you download their app, and since it's on krita.org, people might rightfully think that we are controlling it when we're not.
  • docs.krita.org -> Resources
  • do we want to keep resources like scripts, potentially bundles etc. on our own servers? For now docs.krita.org only accepts links (usually to github etc.)

Related Objects
Search...

tymond created this task.Jul 7 2020, 10:41 PM
tymond triaged this task as Normal priority.
tymond updated the task description. (Show Details)Jul 7 2020, 10:59 PM
brendanbd added a comment.Jul 8 2020, 12:42 AM

Notes:
PEP compliance discussion: https://phabricator.kde.org/T6588

Comments on Maintenance:

In relation to "promise of maintenance" I wrote a script to create a script scaffold (https://phabricator.kde.org/D11275). It was repeatedly broken by later versions of Krita. At the time I was happy to maintain it. Most of the time they were things like API changes or changes to the file structures or what have you, mainly resulting in the script not being registered for loading into the python plugin menu. That is, they were reasonably easy to work around. The trouble was, I never knew it was being broken because I wasn't constantly updating to newer versions of Krita (I suspect that would have all stabilised now) . Indeed, the script itself wasn't so much broken, as it wasn't being registered so was invisible. Being invisible, no one could see that there was something wrong.

So, I guess you need to work out what "promise of maintenance" means in practice, and what is needed to enable that. For example, a per script test suite that could be run automatically would probably be a good idea - to alert developers that they are breaking the script. I would guess that test suites would need to be run from within Krita? That might mean a python test runner built into Krita? Is that kritarunner?

I suspect we also need a generic test to determine whether a script that is in the directory for loading actually succeeds in being registered, otherwise it will fail silently.

Coupled with that is a process to notify the maintainer there's a problem with the script - possibly a comment on the script's task?

rempt added a comment.EditedJul 14 2020, 1:43 PM

We used to have some form of unittesting in the python plugins folder, but that never was integrated with the normal cmake make test run; finding a way to integrate with that should help with actually running tests.

Oh... And now more and more people are using the scripting api, we are still finding errors and misjudgements, so we will probably still be changing things for quite some time.

tymond updated the task description. (Show Details)Jul 15 2020, 3:38 PM