[OPEN-ILS-DEV] Cutting releases

[Dan Scott]

So, on the bright side, we got three releases out today, and turned
around a fix for a critical security problem in minimal time in a
collaborative fashion, and had blog posts and everything.

I have a few concerns, though, which at the risk of sounding overly
negative I'll list out here...

I saw no mention of testing the release tarballs on various distros
before they were released. I had asked for sanity testing of my 2.1.5
tarball but didn't get any response. Security releases suck but still
need QA. How much sanity testing did these most recent releases get?
I thought the outcome of one of the last meetings was that we were going
to adopt a more open security process, one that would enable community
members to contribute towards testing?

Perhaps due to the lack of QA, our 2.2 and 2.3 tarballs once again
contain the full xulrunner binary packages for both win32 and
linux-i686, bloating their sizes by tens of megabytes. Bloat aside,
for legal reasons it's generally not advisable to ship binaries
from other projects if you can avoid it.

I think our release processes need some work.

Exhibit A: Even for a security release, we should be able to prep a
git branch over in the security repo, cut a tarball from it, and
then when the release is announced, just "git push origin security/rel_2_1_5:rel_2_1" 
so that the upstream release branch is a perfect replica of what went
into the tarball.

Instead, at least for the rel_2_1 branch, two times today
commits went into the rel_2_1 branch despite my having painstakingly
prepped a complete branch over in the security repo last night (which
also included commits from rel_2_1_4 that were missing from rel_2_1). I
found that pretty frustrating, although I certainly overreacted today
(probably due to staying up until 2:00 AM to prep the materials for the
release and not getting enough sleep to act like a decent human being).

Exhibit B: We seem to keep stumbling over how to keep upgrade scripts in
sync. Back when I proposed the version-upgrade directory as a means
of stamping out the problems we had historically had with fixes for
point-to-point scripts not making their way into all the right
releases, I also proposed that all point-to-point version upgrade
scripts should be committed first to master, then backported to each
applicable release. Can we commit to taking this approach? Or is there a
better alternative?

Exhibit C: Open-ILS/src/perlmods/lib/OpenILS.pm keeps saying 'our
$VERSION = "2.00";' - in rel_2_1 land I've been trying to remember
to rev that (although I think the 2.1.5 release actually says 2.14 -
sigh).  The release script is all well and good--I believe in better
living through automation--but the script needs regular injections of
human intelligence too. See also QA above! (Aside--what happens when we
get to 2.2.10? Maybe we should be using 2.015, 2.025, 2.033 instead of
2.15, 2.25, 2.33...)

So... maybe we can document our release process a bit more, with a
checklist of steps to follow to create a tarball and of things to QA?

Exhibit D: General confusion around translation processes. They're a
black box for most people, they don't result in quality output for
groups serious about their translations, there's an impedance mismatch
between the tools some translation groups want to use and between casual
translators... we could really use a dedicated translation coordinator
to step up and sort out some improvements on this front. Any volunteers?

On tagging releases:

I've brought this up in IRC a few times, but as far as I can tell the
only reason that we're not using actual "git tag" to create annotated
GPG-signed tags for releases is because one of the git admins doesn't
like git tags. I have to say thanks to Galen for having documented
the procedure for OpenSRF, which has worked well for me over there to
date, and I wish we would use actual tags in Evergreen instead of
branches that are named "tag/blah".

Bah, this probably would have benefited from being broken up into
several different emails, each issue for its own thread. Oh well.