[Koha-devel] RFC: Plugins QA

[Kyle Hall]

>
> If it turns out that a lot of folks are writing plugins or are
> planning to, I think we should encourage them to go through a QA
> process, and creating an official plugin repository would move us
> toward that.


That's pretty awesome! I didn't know there were that many people interested
writing plugins!


>
>
One of my long-standing concerns about the plugin mechanism is that it
> provides a way for developers to bypass the QA process.  Bypassing the
> normal release process is one thing -- sometimes you really, really
> want to deploy a new feature quickly, but the timing may be such that
> it won't be included in a release soon.  Plugins allow developers to
> manage such situations while reducing the temptation to maintain a
> local fork.
>

I totally agree, that was basically the primary reason for adding a plugin
system.


> What would QA mean for a plugin?  I suggest that at minimum, a plugin
> suitable for inclusion in the official repository must meet the
> following conditions:
>
> - It doesn't break core Koha functionality
> - It doesn't do any damage to the server.
> - It doesn't (as far as can be tested) create any additional security
> vulnerabilities.
> - It doesn't *change* core Koha functionality, it just supplies
> additional functionality.
>

This is a fine and sensible list of requirements.

>
> To expand on that last point, a plugin that adds a new report or a
> dashboard obviously doesn't change core functionality.  A plugin that
> adds support for an added content supplier would fall into that
> category as well. What I don't think we should be allowing as official
> plugins are ones that modify deep internal or external behavior.  For
> example, a plugin that completely changed how circulation rules are
> represented could easily turn into a support nightmare.  Imagine a
> discussion like this on the general mailing list:
>
"My loans aren't getting the correct due dates."
> "OK, what version of Koha are you using?  What circ rules have you
> defined".
> "3.14, and thus and such."
> "Hmm, looks like it should be working."
> "But it's not working."
> "OK, I've set up your circ policies on my test database, and it works for
> me."
> "But it's not working."
> "..."
> "Oh, did I forget to mention that I'm using the
> EvergreenStyleCircPolicies plugin?"
> "*sigh*"
>

The plugins system isn't capable of this kind of functionality, so I don't
think we'll have to worry about that.


> On the other hand, the QA barrier for plugins can be lower than for
> core code, since there are some things that are required for core code
> but can reasonably be considered just good ideas for plugins.  These
> include:
>
> - Functioning correctly for all MARC flavors supported by Koha
>

That is good and sound.


> - Supporting I18N/L10N
>

That certainly seems reasonable. I don't know what would be involved with
plugin translation, but the plugins do process templates using Koha's
internal templating system.


> - Supporting library workflows that vary by country
>

I'm not sure what this means, but I don't see any problem with it ; )


> - Obeying all of our stylistic conventions for code.
>

Yes, that is good and sensible. Since plugins are 'wrapped' in the standard
Koha header and footer, it would just be bad ui design not to leverage what
Koha already offers as far as the ui toolkit goes.


> - Having complete unit test coverage
>

For plugins that have unit test-able subroutines, this is quite sensible. I
look forward to seeing what plugins everyone comes up with!


> One thing that just occurred to me is that in addition to distributing
> KPZs, we should encourage plugin authors to lay out their plugins in
> such a way that they can be readily converted to Debian packages.
>

This is something I hadn't thought of. So, my interpretation would be if
you are running Koha from a debian package, you could install  Koha plugins
from packages as well? This is certainly a cool idea.

>
> Another thing we could do is set up a koha-plugins Git repository and
> encourage folks to use it for version control.  We could also consider
> adding "products" to BugZilla for popular plugins.
>

Also a great idea! I was able to modify git-web's snapshot utility to allow
downloading KPZ files directly from our git reposity.

>
> I have a couple general questions: what plugins have folks written to
> date?  What plugins do folks have firm plans to write?
>

Here's what I've done so far:
http://git.bywatersolutions.com/koha-plugins.git

It's really not much.

MARC Checker - This plugin runs each record in the Koha database through
MARC::Lint and tells you how terrible your marc records are ; )
Force Delete Record - Sometimes a record gets corrupted so you cannot even
view the record in Koha ( and thus cannot delete it ). This plugin allows
you to forcefully delete a record by biblionumber.
Rolling Hard Due Dates - This is by far my most complicated plugin, and has
undergone rigorous testing. It allows you to schedule updates to the hard
due dates for circulation rules, and update the due dates for items checked
out that those rules apply to. This was written for a university where they
change the due dates on checkouts near the end of each semester.

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20130531/6e7b170b/attachment.html>