[OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Proposal for release manager

[Galen Charlton]

Hi,

On Mon, Oct 19, 2015 at 11:39 AM, McCanna, Terran
<tmccanna at georgialibraries.org> wrote:
> We would really like to pilot the circ module at some volunteer
>  libraries along with our January 2016 upgrade, but we're still on
> the fence about whether that will be feasible or advisable. Here are
> my biggest outstanding questions at the moment:

The next major Evergreen release is slated for March per both my
proposal and the release tempo we've been following the past couple
years, and the cutoff for feature patches will be in February.
Consequently, while I think it would be very valuable (as a source of
data regarding showstopping bugs) for one or more libraries to make a
serious effort to trial the web staff interface prior to the cutting
of the beta for 3.0, at this point I think you'd have to wait until
closer to your planned upgrade to see if enough of the needed bits
have made their way into the master branch.  (I should also mention
that, per our practice the past year or so, I'm not contemplating
backporting new webstaff code into the current stable branch.)

Of course, I also think it would be prudent to ensure that if you do
proceed with a trial, that the pilot libraries are prepared to quickly
revert to the XUL client if necessary.

> 1 - PRINTING: Printing is still a big question mark for us - we're not going
> to be able to ask our libraries to go through all of the steps currently
> required to get Hatch running. They can use the browser's built-in
> print functionality without hatch, but that's not ideal.

Indeed. The following bug is on point here:

https://bugs.launchpad.net/evergreen/+bug/1489919

I know that Bill Erickson and other KCLS folks are working on Hatch,
and Hatch installation is also on the agenda for the upcoming
Hack-a-way.

> 2 - PATRON RECORD EDITOR: The new patron record editor that
> Bill is/was working on would be one of the best incentives for
> libraries to pilot since they're very unhappy with the performance
> of the current screen - is there a target date for that to be integrated?
> Or are there issues that still need to be resolved before it can be integrated?

Relevant bug: https://bugs.launchpad.net/evergreen/+bug/1452950

Bill Erickson and/or MassLNC would need to comment on timing, as the
branch doesn't have a pull request yet, but it does look like a lot of
good progress has been made on it.

By the way, https://bugs.launchpad.net/evergreen/+bug/1501471 concerns
a patch I wrote that can shave a second or so off the time it takes
for the existing Dojo patron editor to load, and I expect it will be
in a mergeable state soon (and at least one library is using it in
production at the moment).

> 3 - RECEIPT TEMPLATE EDITOR: Since this functionality isn't complete
> until after Sprint 3, and the libraries won't be able to modify the receipt
> templates yet, we need to find a way to customize the transit slips so
> they'll print out properly for the needs of our statewide courier. We can
> probably do this on the server side, but I haven't tried yet.

It indeed is possible to override the templates server-side, e.g.,
templates/staff/share/print_templates/t_hold_transit_slip.tt2.

> 4 - STANDALONE: Can staff have the regular client installed in order to take
>  advantage of the standalone functionality when needed, but still use the web
> client for normal online use? Or will there be conflicts if they try to switch from
> one to the other on the same circ computer?

There will be nothing preventing using both the web staff interface
and the XUL client on the same computer, although as a matter of
procedure, it would be a good idea to ensure that the circ staff fire
up the XUL client only for specific purposes (such as using offline
circ).

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org