Hi, On Thu, May 30, 2013 at 9:00 AM, Tomas Cohen Arazi <[email protected]> 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: [email protected] 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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
