Re: [OPEN-ILS-GENERAL] community support policy for Evergreen releases?

2011-09-26 Thread Duimovich, George

There's going to be folks who can upgrade 'the day of release' and others with 
constraints that prevent those just-released upgrades from happening in a 
timely manner (e.g. larger consortia, academics with school term timing issues, 
etc.).

So supporting older versions is important, but I'm for the view that we don't 
go too far back with that, given how important it is to keep the Evergreen 
train moving fast and development/support resources focussed.

To make it easier and help manage the pace of upgrades, I'm always recommending 
to potential new users to look into negotiating vendor support agreements that 
come with X free upgrades - this has helped us critically from time to time. 
Also nice that Canadian / US holidays don't always match up, so convenient to 
pass the buck once in a while to help manage upgrades esp. during those lazy 
summer holidays. 

Also related to keeping up with the upgrades:

1) The patching and bug fixing seems to be fast - like lightning fast in most 
cases - and this seems to be getting better as there are more of us out there 
to test new releases, but a bit more QA somewhere in the chain could help 
reduce the number of minor dot (re)-releases, which in turn might reduce any 
upgrade fatigue for some users and/or helping better conserve upgrading 
resources for the major releases. 

2) Re-integrating our customizations - continues to be a pain point. To be 
clear, this is a nice problem to have given that previous ILS didn't have this 
problem -- i.e. wouldn't let us customize. And there's been significant 
progress since we started on 1.4 (yah!), but I've often thought that our 
in-house upgrade checklist has a few too many little gotchas to review with 
each upgrade. With the experience we have now, it's no big deal but a bit 
annoying when other issues also come into play to burn into the upgrade 
process.  It doesn't help that most IT units are being squeezed to do more with 
less, so important that we continue to make headway towards customization-happy 
upgrades
(TT opac and other planned changes to help) and staff-client friendly 
auto-updates, etc.

I'm not sure where the sweet spot lies with selecting time-based support 
periods (tough love approach) and/or more structured Long Term Support 
releases but I guess what we're trying to avoid here is the problem that 
plagues other ILS communities: namely, lots of end users running way out of 
date systems, then running into troubles with support and/or consuming limited 
resources on yesterday's problems (ultimately leading to more expensive 
upgrades down the road and a bad rap for rest of community). 

Finally, hosted options offer *some* libraries an extremely good option to 
resolve the keeping up-to-date problem, so I'd anticipate that long term 
support is not as critical as it may have in the past. 

George
George Duimovich
NRCan Library / Bibliothèque de RNCan






-Original Message-
From: open-ils-general-boun...@list.georgialibraries.org 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jason 
Etheridge
Sent: September 23, 2011 15:33
To: Evergreen Discussion Group; Evergreen Development Discussion List
Subject: [OPEN-ILS-GENERAL] community support policy for Evergreen releases?

During the Community meeting in IRC today, I asked if we really want to push 
out 2.2 quickly, might we extend support for whatever version would be falling 
off the support truck?  or is that a bad idea?

According to the last policy we came up with, 1.6 would be deprecated as soon 
as 2.1 hits, and 2.0 will be deprecated as soon as 2.2 hits.
There were musings about time-based support periods and Long Term Support 
releases, and it was decided we'd talk about such things on list.

So.  Discuss. :)

--
Jason Etheridge
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  ja...@esilibrary.com
 | web:  http://www.esilibrary.com


Re: [OPEN-ILS-GENERAL] community support policy for Evergreen releases?

2011-09-26 Thread George Tuttle
Is there a process for beta testing Evergreen?

George Tuttle
Computer Services Librarian
Piedmont Regional Library System
770-867-2762 x113
770-891-0654 (cell)
770-867-7483 (fax)
gtut...@prlib.org


-Original Message-
From: open-ils-general-boun...@list.georgialibraries.org
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of
Duimovich, George
Sent: Monday, September 26, 2011 12:06 PM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] community support policy for Evergreen
releases?


There's going to be folks who can upgrade 'the day of release' and others
with constraints that prevent those just-released upgrades from happening in
a timely manner (e.g. larger consortia, academics with school term timing
issues, etc.).

So supporting older versions is important, but I'm for the view that we
don't go too far back with that, given how important it is to keep the
Evergreen train moving fast and development/support resources focussed.

To make it easier and help manage the pace of upgrades, I'm always
recommending to potential new users to look into negotiating vendor support
agreements that come with X free upgrades - this has helped us critically
from time to time. Also nice that Canadian / US holidays don't always match
up, so convenient to pass the buck once in a while to help manage upgrades
esp. during those lazy summer holidays. 

Also related to keeping up with the upgrades:

1) The patching and bug fixing seems to be fast - like lightning fast in
most cases - and this seems to be getting better as there are more of us out
there to test new releases, but a bit more QA somewhere in the chain could
help reduce the number of minor dot (re)-releases, which in turn might
reduce any upgrade fatigue for some users and/or helping better conserve
upgrading resources for the major releases. 

2) Re-integrating our customizations - continues to be a pain point. To be
clear, this is a nice problem to have given that previous ILS didn't have
this problem -- i.e. wouldn't let us customize. And there's been
significant progress since we started on 1.4 (yah!), but I've often thought
that our in-house upgrade checklist has a few too many little gotchas to
review with each upgrade. With the experience we have now, it's no big deal
but a bit annoying when other issues also come into play to burn into the
upgrade process.  It doesn't help that most IT units are being squeezed to
do more with less, so important that we continue to make headway towards
customization-happy upgrades
(TT opac and other planned changes to help) and staff-client friendly
auto-updates, etc.

I'm not sure where the sweet spot lies with selecting time-based support
periods (tough love approach) and/or more structured Long Term Support
releases but I guess what we're trying to avoid here is the problem that
plagues other ILS communities: namely, lots of end users running way out of
date systems, then running into troubles with support and/or consuming
limited resources on yesterday's problems (ultimately leading to more
expensive upgrades down the road and a bad rap for rest of community). 

Finally, hosted options offer *some* libraries an extremely good option to
resolve the keeping up-to-date problem, so I'd anticipate that long term
support is not as critical as it may have in the past. 

George
George Duimovich
NRCan Library / Bibliothèque de RNCan






-Original Message-
From: open-ils-general-boun...@list.georgialibraries.org
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of
Jason Etheridge
Sent: September 23, 2011 15:33
To: Evergreen Discussion Group; Evergreen Development Discussion List
Subject: [OPEN-ILS-GENERAL] community support policy for Evergreen releases?

During the Community meeting in IRC today, I asked if we really want to
push out 2.2 quickly, might we extend support for whatever version would be
falling off the support truck?  or is that a bad idea?

According to the last policy we came up with, 1.6 would be deprecated as
soon as 2.1 hits, and 2.0 will be deprecated as soon as 2.2 hits.
There were musings about time-based support periods and Long Term Support
releases, and it was decided we'd talk about such things on list.

So.  Discuss. :)

--
Jason Etheridge
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  ja...@esilibrary.com
 | web:  http://www.esilibrary.com