[OPEN-ILS-DEV] Proposal for release manager

[Galen Charlton]

Hi,

Here are my plans for the next Evergreen release if I'm elected as
release manager.

Release priorities
-------------------------------------
[1] Extend support for production use of the web staff interface at
circulation desk

As of today, the first sprint for the web staff interface is complete,
and the second sprint (cataloging) is wrapping up the phase where bugs
reported by the funding partners are being fixed.  Coding for sprint 3
(administration and reports) is under way, as is a project to write an
AngularJS patron record editor.

At present, the web staff interface has been included in Evergreen as
a technology preview and we have explicitly recommended against using
in production.  For the next release, I propose that we extend
community support for using the web staff interface in production for
circulation desk functions, including:

- patron registration and editing
- circulation, hold and monetary transactions conducted at the circ desk

In order to accomplish this, we'll need to

- clearly identify the patron and circ functionality that we'll
"officially" support
- identify any bits of circ functionality that may need to continue to
rely on the XUL client
- write sufficient documentation of the new interfaces
- create a mechanism so that web staff interface functions that aren't
quite ready for prime time can be hidden from the circ desk
- stamp out any showstopper bugs

As release manager, I would participate in all of these tasks, but of
perhaps more import, would do what I can to remove any roadblocks
preventing any interested contributors from participating in this
effort.

[2] Rescue patches in need of unit tests

As release manager, I intend to actively comb through pull requests
that lack unit tests and bring them up to current standards.

[3] Deprecate HTTP in favor of HTTPS

Using HTTP presents a risk to the privacy of library patrons, and it
is clear that the trend for web applications is to use HTTPS across
the board.  At the same time, projects like Let's Encrypt are lowering
the bar for easily (and cheaply) obtaining SSL certificates.
Consequently, for the next release I propose that:

- the default configuration for new installations of Evergreen (and
OpenSRF) not enable HTTP
- we provide upgrade instructions for disabling HTTP (except for the
purpose of immediately redirecting to HTTPS)
- we tie up any mixed-content loose ends

[4] Document ways to use SIP2 more securely

SIP2 is another unencrypted protocol, and one that many libraries are
stuck using for the moment.  For the next release, I propose that
Evergreen distribute example configurations and documentation on how
to tunnel SIP2 traffic (e.g., via stunnel or SSH).

Because this release would be the first where (a portion) of the web
staff interface would be meant for production use, I propose that we
call it 3.0.0.

Schedule
-------------------------------------
* 5 February 2015: feature slush - at this point in the release, all
significant feature branches should have LP bugfixes and pull
requests. I would reserve the right to bump any new feature branches
that come in after this date to the fall 2016 release.
* 19 February 2015: feature freeze - no non-bugfix patches to be pushed
* 25 February 2015: beta release
* 10 March 2015: release candidate
* 17 March 2015: 3.0.0 released

Questions? Please don't hesitate to ask me.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
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