Proposal for RM 3 18 tcohen
This is my proposal to serve as Release Manager for Koha 3.18.0.
Overview
The Koha community has a well established workflow for test-driven development. I’d like to see our team continue with this solid approach of cooperative development, finding out where the bottlenecks are and providing a workaround where needed. My main goals if elected would be:
- Continue Galen’s effort on “everything needs a unit test”. More documentation on ‘best practices’ would be great. This matter should be subject to broader discussion with the QA team (and the rest of the dev team).
- Trust a team of elected Module Maintainers (at least) for critical modules maintenance.
- End-user in mind.
- Codebase maintenance.
Release management: a team
Even when the RM retains the ultimate right to decide what does or does not get pushed to master, I’d encourage people from the QA team and past release managers/maintainers to become Module Maintainers. Communication would be key, and pull-requests from topic branches would be my ultimate goal for this term.
Major goals
As every RM, I’ll try to reduce the backlog of patches that always accumulates over time. I also have some specific goals:
- Help people working on search engine abstractions and search code refactorization get their work ready for production.
- Prepare for a convergence between the-packages-way and source installs. A new ‘cluster’ install method for source code installs might emerge.
- I’d like to see some project source code reorganization. This could only happen if we provided some backwards compatibility.
Timeline
- I’d keep the current 6-month timeline for the release (dates may vary), thus:
- May 2014 (after 3.16 is released): I’d start pushing to master, for 3.18.0
- September 2014: Probably some pre-pre-alpha 3.18 - after this point, major architectural changes will be discouraged
- End of September 2014: (Soft) Feature slush
- October 2014: Feature freeze
- November 2014: String freeze
- End of November 2014: release of 3.18.0