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

[Tim Spindler]

Personally,  I'm all for a time released as Dan indicates below.  It is
much easier to plan and something like the Fedora schedule works well  (I
really like the detail of the Fedora schedule also).   I'm just not sure
what is a realistic time frame between feature freeze and general release.
 If a feature can't make the deadline, it would have to be included in the
next release.    As a manager, that would make things a lot easier from my
stand point.

Tim Spindler
Manager of Library Applications
C/W MARS

On Tue, Dec 20, 2011 at 5:34 PM, Dan Scott <dan at coffeecode.net> wrote:

> 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!
>



-- 
Tim Spindler
tjspindler at gmail.com

*P**   Go Green - **Save a tree! Please don't print this e-mail unless it's
really necessary.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.georgialibraries.org/pipermail/open-ils-documentation/attachments/20111220/f969cb5b/attachment-0001.htm>