[Koha-devel] RFC: Plugins QA

[Galen Charlton]

Hi,

On Thu, May 30, 2013 at 9:00 AM, Tomas Cohen Arazi <tomascohen at gmail.com> wrote:
> So, I belive we should discuss the creation of a sort of "Official plugins
> repository" where QAed plugins could be uploaded.

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.

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.

But wanting or needing to release functionality sooner than the normal
release schedule permits is of course no excuse for not doing QA.

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.

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

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
- Supporting I18N/L10N
- Supporting library workflows that vary by country
- Obeying all of our stylistic conventions for code.
- Having complete unit test coverage

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.

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.

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

Regards,

Galen
--
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org