[OPEN-ILS-GENERAL] Release manager / management / process? (was: Official EOL Policy)

[Dan Scott]

On Tue, Dec 20, 2011 at 03:38:45PM -0600, Anoop Atre wrote:
<snip> 
> Maybe what we need to plan next is a release manager with a big stick?

I'm curious if you have some concrete ideas of how a "release manager"
would contribute to the project? I've heard this idea floated before in
other discussions, but in practice just naming somebody a "release manager"
wouldn't solve anything. Maybe there are some implicit ideas about what
such a position would do or how they would affect the project's release
cycle that we can flesh out, and then determine whether
creating/naming/empowering a position is the right answer, or whether
there are other things that we can do to improve our release processes,
or both?

For example: if one of the goals of having a release manager would be to
ensure that our releases are well tested in environments that reflect
the breadth of our current or target adoption base of libraries, I don't
think we would expect the release manager to then be responsible for
setting up all of those environments, creating all of the test data with
all of the variable org unit settings, and testing branches across all
of these environments to ensure that the upgrade scripts work and that
there are no regressions before pushing the branches to master.

Perhaps, in addition to the to-be-written Evergreen release cycle
document, we could articulate the general goals that we want to achieve for
a given release (e.g. "Supports a clean upgrade from previous release",
"Maintains or improves performance over the previous release, broken
down by 1. search, 2. circulation speed, 3. etc", "Offers a fully
translated public interace in the following locales", "All new features
have an overview in Release Notes and more detailed documentation in the
manual", etc). Then, after each release, we could do a "quick" evaluation
(hah) and post-mortem to see where we fell short of our goals, and come
up with ideas on how to address those shortcomings in the next release.

Anything we do depends heavily on buy-in from contributing parties,
of course.