[OPEN-ILS-GENERAL] [OPEN-ILS-DOCUMENTATION] [OPEN-ILS-DEV] Official EOL Policy

[Dan Scott]

On Tue, Dec 20, 2011 at 03:42:52PM -0500, Kathy Lussier wrote:
> Thanks for forwarding this along Anoop! I think the time-based releases will
> be very helpful as institutions plan their upgrades, and a 15-month support
> cycle seems reasonable. In general, I would say this is a positive move
> forward.
> 
> I do have questions regarding this next release of 2.2 that, according to
> the policy, would be coming out in March. I don't know that anyone has
> answers to these questions yet, but I'm curious as to when certain steps
> need to be taken to get to a full release in March. In looking at the

Right, in the past we've kicked around the idea of coming up with
something like http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
for Evergreen - and with a move towards time-based releases, rather than
feature-based releases, this becomes much more relevant and useful.
Anyone want to tackle creating the equivalent for Evergreen releases?

> release schedule for 2.1, beta was released on May 5, 2011 and 2.1.0 was
> released five months later in early October. Looking at the logs from
> today's developer's meeting, it looks like an alpha2 release for 2.2 is in
> the works for the beginning of the new year. Is there an expectation that
> the 2.2 release cycle will be faster than the one for 2.1? To get to a March
> release, what is the drop dead date for getting a 2.2 beta and a subsequent
> release candidate?

Great questions! First, I would argue that much of the delay that we
previously experienced between "beta" and "GA (general availability)" of
the release was due to the focus on features and the attempt to shoehorn
things into the release that had not been properly tested. I also think
that this explains much of the initial instability for the first few
point releases.

Shortly after moving to git as a version control system in May 2011, we
also adopted a "sign-off" procedure that, in essence, means that nobody
should commit their own code directly to master. We ask that another
developer review and test the code and add their sign-off to the commit
to help ensure that the quality of the code is high and that no
overlooked problems or edge cases creep in. Thus, for the most part,
master has stayed relatively stable (despite my ability to slip in a
problem here and there).

There have been a few "merge binges" where, in an attempt to clear a
backlog of unreviewed branches / launchpad bugs, a number of branches
were committed to master with less rigorous testing (mostly an
eyeballing of the diffs), but I have noted my nervousness about the
effect of these sorts of binges on the quality of master (and I don't
think I'm alone on that). 

So how do we enable progress on master without forcing developers to act
at half-speed because they're also doing all of the reviewing and
testing of other developers' branches? During today's meeting we agreed to
call for community help in testing & reviewing proposed branches.

On that note: I would like to reiterate that anyone with the ability to
push to the Evergreen working repository has the ability to merge a
branch to master, test it out, push their signed-off branch to the
working repo, and note that they've tested the branch and pushed a
signed-off branch in the related bug - at which point a committer can
push that signed-off branch directly to the master repo. So committers
shouldn't be a bottleneck if we can get enough people with the ability
to build and run Evergreen from source to tackle branches.

If there's anything that developers can do to help reviewers/testers
review and test branches, please let us know! Clearer guidelines on git
usage? Recommended test plans inside the bug that points to the branch?
Test data? Links to lists of bugs that need testing & sign-off like
http://goo.gl/3EAzQ ?
 
> In the spirit of full disclosure, there is a bit of self interest in my
> questions as there is a MassLNC consortium that needs functionality
> available in 2.2 (some of which was merged into master way back in early
> July) before going live on Evergreen. We would love to see a release
> candidate for 2.2 in January, and, given the schedules I've seen for past
> release, it seems like this would need to happen fairly soon if a full
> release were to come out in March.

The good news for you is that (unless something horribly bad turns up),
anything in master will be in the next release. And I strongly believe
that if we go with time-based releases in combination with reviewed /
signed-off commits, then we should be able to produce much higher
quality releases right out of the gate at regular and predictable
intervals.

So I do think that Anoop's example dates of a beta at the end of
January, an RC at the end of February, and a GA at the end of March are
pretty attainable _if_ we stay strict about reviewed / signed-off
commits. For all intents and purposes, once we hit RC then all focus
should be on ensuring the migration path is clean, and tackling new
bugs that pop up due to exposure to production data, and ensuring our
release notes / documentation is in reasonable shape. (Aside: we'll be
keeping release notes in the source tree under the docs/ directory, so
that in theory when we commit a new feature we can add a basic overview
of the new feature / behavior change to the release notes at the same
time - we're starting a bit late for 2.2 so we'll see how it goes but
there's always 2.3!)

If, however, we yield to the temptation to rush untested code into
master, then we likely face either hitting the March date with a lower
quality GA, or slipping the March date.

P.S.
Fight the merge binge! Get involved in testing & sign-off!