Monthly missive from the 3.12 RM (#1)

Welcome to this, my first newsletter as RM. It has been six weeks since the release of 3.10.0. In those six weeks, a lot has happened: 245 patches by 36 developers have been committed.

Major developments

* Bug 7067 – patron self-registration
This feature makes it possible for patrons to edit their own contact information, as well as register for new accounts.
* Bug 8377 – support for embedding HTML5 media in a tab in the details value
This feature allows the playing of media formats supported by HTML5 directly in the web browser.
* Bug 7919 – associate authorized values and patron attributes with specific branches
This feature allows different libraries in the same system to use different authorized values and extended patron attributes.
* Bug 8559 – resolve conflicting item statuses when checking out items that are on hold
Prior to this patch, if a librarian checked out a waiting hold to a different patron it gave the item conflicting statuses. The item showed as both checked out to the different patron, and waiting for the original patron. This has been fixed.
* Numerous Plack and DEBUG-related fixes
Many minor — and not so minor — problems with the DEBUG setting and Plack have been resolved.

Policy

These past six weeks have also seen some changes in release policy. In particular:

Coding guidelines

The coding guidelines have been updated with more details and additional rules (see, for example, PERL14-PERL17). See http://wiki.koha-community.org/wiki/Coding_Guidelines

Commit messages

Good commit messages are crucial for the Quality Assurance process. In light of this, we have new detailed (and mandatory) guidelines for commit messages which should help developers write more useful commit messages. Highlights include a requirement for:
1) an explicit description of what the patch is supposed to do, and
2) a test plan

See http://wiki.koha-community.org/wiki/Commit_messages

Patch reversion

One of the tools in the Release Manager’s toolkit is “git revert” which allows me to easily remove patches that are causing problems from master. After a lot of consideration, I have come to the conclusion that by reverting problematic patches quickly I can ensure that master remains as stable as possible while still taking advantage of the combined testing might of the entire developer community. For the rest of this release cycle I intend to swiftly revert any patches that cause blocker-level bugs and request follow-ups/revisions from the original developer.

I did this, for example, with bug 7167, a new non-linear database update mechanism. I believe that bug 7167 represents an important and useful advance for Koha. However, when I pushed it, jenkins quickly alerted us that it was impossible to install Koha on a clean system. Rather than leave master in an unusable state, I reverted the patch, and there have been several follow-ups addressing some of the problems we identified. Once they have been tested, signed off, and QAed, I will push the entire patchset again, hopefully without any unwanted side effects.

RM’s role in QA

In contrast to the practice during some of our previous release cycles, I have made the decision to NOT QA patches that have been signed off and are awaiting QA (for the most part; I will address the exceptions to this below). I have made this decision for two reasons:
1) Any patch I QA has one fewer sets of eyes on it between composition and pushing.
2) The QA team was elected by the community in order to QA patches. I feel it is not my place to gainsay the community’s decision to elect a QA team, at least when I can avoid it.

There is, however, an exception to this: for patches where no member of the QA team can test the patch, I will — regretfully — QA the patch.

What comes next

There are still 111 patches awaiting signoff and 66 patches that have been signed off and are awaiting QA. Please take a few minutes to sign off on a patch or two, or, if you are on the QA team, QA a patch or two.

Over the next month I look forward to pushing a lot more patches, and seeing a lot more advancement in Koha as we move toward 3.12. In January I intend to release a first “preview” of 3.12 so that non-developers interested in taking a peek at 3.12 can do so.