[OPEN-ILS-DEV] RFC - Release Manager

[Galen Charlton]

Hi,

As a discussion item for the developers' meetings during the Evergreen conference, I would like to formally float a proposal: it's time to name a release manager.  This would be a committer who is tasked with:

- proposing a schedule for the next release
- making sure that the next release comes out on time (or at least a much better approximately of "on time" than what we've managed with 2.2)
- acting as final, neutral arbiter of what does or does not make it into a release
- helping to coordinate the efforts of coders and testers to make sure that patches are looked at on a timely basis
- in conjunction with DIG, making sure that releases are accompanied by good release notes

Some specifics of my proposal:

[0] During his or her term, the release manager would the designated primus inter pares among the code committers.
[1] We'd treat naming an RM as an experiment to start.  In other words, the release manager would be responsible for releasing 2.3; once 2.3.0 is released, we would decide whether to continue naming an RM, and if so, who the next one should be.
[2] Unlike the Koha project (which I'm using as a model for much of this), the release manager would not act as the sole bottleneck for patches to flow into the master branch -- in other words, every committer would remain empowered to sign off and push patches.  However, the release manager would be the designated final arbiter in case any otherwise-unresolvable technical disagreements come up.  Also, particularly as we get close to the scheduled release day, the release manager would have the authority to decide what should stay *out* of the release branch.
[3] The release manager would be responsible for giving the community some kind of public update on the progress of the release at a predictable frequency.

I've intentionally excluded the question of releasing 2.2 from this proposal.  Of course, we need to nail that release down soon, but if we can manage that, it would give the RM a clean slate for the next major version.  Also, this proposal assumes that we'll decide to make another go at time-based releases.

I would appreciate comment on this proposal, and I would also ask that anybody who might be interested in acting as RM to put their name forward along with details of the schedule they would propose for 2.3.

Regards,

Galen
--
Galen Charlton
Director of Support and 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