Re: [OPEN-ILS-GENERAL] Evergreen and RDA

[Ben Shum]

Hi Sue,

I'd like to mention this thread discussing 264 and RDA: 
http://markmail.org/message/dtubcqbpkt3xil6s


And also this bug ticket that is being used to track further discussion 
and ongoing work: https://bugs.launchpad.net/evergreen/+bug/1071505


My comment (#8) on the bug ticket describes a potential display fix for 
TPAC, but there's still a ways to go before completely including 264 as 
an option for publication information.


-- Ben

On 01/09/2013 05:54 PM, Sue Graziano wrote:
When downloading RDA records, the  264 field does not appear in the 
catalog.  The work around is to add a 260 field. Has any library found 
a way to view the 264 in the Evergreen catalog?


Thank you

--
Sue Graziano
Collection Development Librarian
Santa Cruz Public Libraries
117 Union St.
Santa Cruz, CA  95060
grazia...@santacruzpl.org 
 (831) 427-7700 x7725 


--
Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070, ext. 113

[OPEN-ILS-GENERAL] Evergreen and RDA

[Sue Graziano]

When downloading RDA records, the  264 field does not appear in the
catalog.  The work around is to add a 260 field.  Has any library found a
way to view the 264 in the Evergreen catalog?

Thank you

-- 
Sue Graziano
Collection Development Librarian
Santa Cruz Public Libraries
117 Union St.
Santa Cruz, CA  95060
grazia...@santacruzpl.org
 (831) 427-7700 x7725

Re: [OPEN-ILS-GENERAL] Proposal to change Evergreen versioning scheme

[Dan Scott]

On Wed, Jan 09, 2013 at 02:07:58PM -0500, Kathy Lussier wrote:
> Hi Alexey,
> >>I think a lot of the "Is it going to be a huge pain to upgrade? Or is it
> >>just a minor upgrade?" angst would be diminished if we (devs and release
> >>managers) did a better job of communicating expectations about each
> >>upcoming release. We pledged to do this at EGConf 2012 and had a good
> >>start, but need to stay vigilant on this front - and pitch in on the
> >>documentation (release notes & upgrade notes).

> >I agree and would like to offer my help with this, however, not sure exactly 
> >how at this point.

> Here are some thoughts on pitching in on the release notes front.
> When I'm in Launchpad, I have started using a needsreleasenote tag
> for pullrequests for release-note-worthy new features that don't
> already have release notes. The development community has adopted a
> practice of writing the release notes when they submit code for new
> features, but this doesn't happen in all cases, meaning that we
> don't have a comprehensive set of release notes at beta time. I
> haven't gotten very far in adding this tag to new feature
> submissions, and I'm sure there are probably several Launchpad
> submissions that should get this tag. I'm hoping it will result in
> more comprehensive release notes at beta time.

Towards this end, during last month's dev meeting I pointed fellow devs
at a sign-off review checklist -
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:signoff_review_checklist
- that includes the question "Does this commit have an associated
release notes entry, if applicable? New features, new config.tt2
entries, new user or org unit settings, changes in behaviour should have
a release notes entry."

People seemed to like the checklist idea, but I'm not sure how to
implement it. Maybe have people copy the checklist results into
Launchpad when they sign-off?

Re: [OPEN-ILS-GENERAL] Proposal to change Evergreen versioning scheme

[Kathy Lussier]

Hi Alexey,

I think a lot of the "Is it going to be a huge pain to upgrade? Or is it
just a minor upgrade?" angst would be diminished if we (devs and release
managers) did a better job of communicating expectations about each
upcoming release. We pledged to do this at EGConf 2012 and had a good
start, but need to stay vigilant on this front - and pitch in on the
documentation (release notes & upgrade notes).

I agree and would like to offer my help with this, however, not sure exactly 
how at this point.
Here are some thoughts on pitching in on the release notes front. When 
I'm in Launchpad, I have started using a needsreleasenote tag for 
pullrequests for release-note-worthy new features that don't already 
have release notes. The development community has adopted a practice of 
writing the release notes when they submit code for new features, but 
this doesn't happen in all cases, meaning that we don't have a 
comprehensive set of release notes at beta time. I haven't gotten very 
far in adding this tag to new feature submissions, and I'm sure there 
are probably several Launchpad submissions that should get this tag. I'm 
hoping it will result in more comprehensive release notes at beta time.


Another way to help is to go through the Change Logs to verify that 
release-worthy new features are reflected in the Release Notes and add 
any that aren't there. I have done this a couple of times, and, although 
it is a little tedious, it is a good way to catch new features that may 
be missing from the release notes.


Kathy

Re: [OPEN-ILS-GENERAL] Proposal to change Evergreen versioning scheme

[Lazar, Alexey Vladimirovich]

On 2013-01-04, at 14:52 , Dan Scott  wrote:

> On Fri, Jan 04, 2013 at 03:21:08PM -0500, Rogan Hamby wrote:
>> I would disagree.  It's not this one:
>> http://www.open-ils.org/dokuwiki/doku.php?id=versioning
>> 
>> But, I would propose that we are following one based largely on the
>> developer's perception of what are major and minor features and impact for
>> users.  I've been there for a few of those discussions and those were the
>> concerns voiced when discussing version numbers.  Unintentional?  I can't
>> speak to that.  But, to me what is already being done, as abstract and ill
>> defined as it is (and I think that is part of what bothers some) - works.
>> I'm fine with things as they are.  It works with the larger community's
>> goals (or at least mine) and a raw number means something to the front line
>> users.
> 
> If we had a marketing team, and they had done some research that showed
> that version numbers actually matter when it comes to perceptions of a
> library system's stagnation (or not) and adoption of said system, then I
> would defer to their decision. But as far as we know, we don't have a
> marketing team, and I haven't seen any citations about such research on
> generic software products in the discussion to date.

I agree, and it is unlikely that we ever will.

> 
> On the argument that we're not following our current versioning scheme
> criteria around the major number - I like James' pointer to the semantic
> versioning proposal, and that fits quite well with library
> versioning semantics that we're already doing (to some extent) via
> autotools.

So do I, it really makes sense. However, assuming that Evergreen's declared 
versioning scheme was not maintained due to additional time required to manage 
it, this too may not work too well.

> 
> That said, given that some major piece of infrastructure is likely to
> always change (Dojo or PostgreSQL or XULRunner or Apache or any of the
> other umpteen dependencies that we have), we could either strike the
> pertinent clauses from the versioning scheme in the wiki, or alter it to
> say that it will be incremented when major features are added.

As was done. Now I think it would be a good idea to formalize how the process 
of determining "new major features" works. Will this be decide by the release 
manager?

> I don't like the date approach very much as, although we've agreed to
> time-based releases, we've also agreed to let the release date slip if
> there are known blockers. So we could end up with 13.04 / 13.11 / 14.05
> / 14.10, and that would lead to references to 13.10 having to be updated
> in multiple places to 13.11 if we slip. Bah.

I agree that would be confusing. If this scheme were adopted, the version 
number should stay static based on the release schedule, and not the actual 
release date.

> I think a lot of the "Is it going to be a huge pain to upgrade? Or is it
> just a minor upgrade?" angst would be diminished if we (devs and release
> managers) did a better job of communicating expectations about each
> upcoming release. We pledged to do this at EGConf 2012 and had a good
> start, but need to stay vigilant on this front - and pitch in on the
> documentation (release notes & upgrade notes).

I agree and would like to offer my help with this, however, not sure exactly 
how at this point.

> I will admit to suffering from fatigue around this discussion, which
> last came up in May:
> http://libmail.georgialibraries.org/pipermail/open-ils-dev/2012-May/008203.html

Yes. In the second paragraph on 
http://libmail.georgialibraries.org/pipermail/open-ils-dev/2012-May/008237.html,
 I touted my suggestion for hands-off scheme as a type of a solution for this.

> In the end, I'd really like to not have this discussion come up on a
> regular basis. There's code and docs and tests and websites to be worked
> on, and a product that is solid and reliable and easy to understand and
> use is going to succeed no matter how much the version numbers diverge
> from the scheme documented on a wiki page. And if the current problem
> can be rectified by striking out two clauses from the wiki page, why
> don't we just do that so we can focus on everything else we have to work
> on?

Yes, but someone still has to decide what constitutes "major feature updates". 
So, this change does not really eliminate future discussions about whether or 
not to increment version numbers. Also, major feature updates have occurred 
since version 2, but the version numbers stayed the same. So, should the next 
version be 3?  

Aleksey Lazar
PALS
IS Developer and Intergrator
507-389-2907
http://www.pals.org/
alexey.la...@mnsu.edu

[OPEN-ILS-GENERAL] ***SPAM*** Re: Proposal to change Evergreen versioning scheme

[Lazar, Alexey Vladimirovich]

On 2013-01-04, at 10:41 , Galen Charlton  wrote:

> Hi,
> 
> On Fri, Jan 4, 2013 at 7:07 AM, Bill Erickson  wrote:
> If we decide to change, I would also vote for the Ubuntu-style naming scheme 
> Thomas describes.  (IIRC, Jason S. was also a proponent of this scheme). 
> 
> All that I ask of a version number that it increase monotonically, not be 
> unreasonably long, and that if there are any semantics attached to the 
> version numbering scheme that set expectations for ease of upgrades [1], that 
> they be adhered to.

I am actually neutral on whether or not we use a Ubuntu-style versioning scheme 
specifically, e.g., using the last two digits of the year. I proposed to use a 
scheme based on last digit of the year specifically to provide a natural 
monotonically increasing path to make a transition to a calendar-based 
versioning scheme from current 2 to 3.

> 
> I have no objection to switching to an Ubuntu-style scheme (so if we're 
> voting, consider this a 0), though I would also point out that doing so means 
> that we would lose the ability to increment the version number significantly 
> to signal a truly major new release.  For example, without reading the 
> release notes, there would be nothing to indicate whether (say) Evergreen 
> 13.10 adds just a few nice features over 13.04 or if it adds two new major 
> functional modules.

I agree this is a valid concern. However, many new features and significant 
changes have occurred to Evergreen since version 2.0 and the version was not 
incremented. So, even though this is a valid concern, perhaps this is more of a 
theoretical than practical loss at this point.

> 
> That said, I don't think that version numbers are of that much consequence in 
> marketing Evergreen -- the advent of major new features  (serials! 
> acquisitions! robotic book returners!) matters rather more to library staff 
> who are anticipating an upgrade.

I agree that major new features are the "meat" of marketing Evergreen to new 
libraries, but I also think that having *some type* of a steady progress in 
version numbering also helps on some level.   

> 
> [1] For example, the PostgreSQL project's policy at 
> http://www.postgresql.org/support/versioning/ specifies that minor release 
> upgrades will never require a dump/restore of the database.

Speaking purely as my opinion, I think that having stable long spans of time 
between major database versions of PostgreSQL is sort of useful for sanity of 
DB admins and those who write and maintain software that depends on it. Also my 
opinion is that for PostgreSQL specifically, it is far more crucial to maintain 
a strict versioning policy that is tied to backward compatibility, among other 
things, because many systems and software depend on those features. Evergreen 
does not really have any other software depend on it in the same fashion.

Aleksey Lazar
PALS
IS Developer and Intergrator
507-389-2907
http://www.pals.org/
alexey.la...@mnsu.edu

[OPEN-ILS-GENERAL] telnet client Re: Proposal to change Evergreen versioning scheme

[Jason Etheridge]

> You can have that now:
>
> http://git.mvlcstaff.org/?p=jason/issa.git;a=summary

Ooh, will need to try that.

-- 
Jason Etheridge
| Support Manager
| Equinox Software, Inc. / The Open Source Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: ja...@esilibrary.com
| web: http://www.esilibrary.com

[OPEN-ILS-GENERAL] marc overlays

[Anne Murray]

I am trying to overlay full marc records for DVDs on to a short record. The
short record has the UPC in field 020 and the proper record has it in field
024. Is it possible to write a match set that will overlay this, or is it
the case that only 020 can overwrite 020 and nothing else?

Anne Murray
East Dunbartonshire Libraries
Glasgow
Scotland

Re: [OPEN-ILS-GENERAL] Evergreen & ebooks

[Jason Stephenson]

Quoting Donald Butterworth :


Colleagues,

I'm looking for some insights into how Evergreen libraries handle eBooks.
Here is the scenario:

We have access to a large number of ebooks because of a subscription to a
database. Titles that are available as part of a subscription, can be added
to or deleted at the whim of a publisher or vendor. So, do you include
bibliographic records for those titles in Evergreen? If you do, is there a
way that Evergreen can do a batch delete based on a list of titles supplied
by the subscription database vendor?


We use this: http://git.mvlcstaff.org/?p=jason/safariload.git;a=summary

It works for our Safari Books Online subscription. The only other  
ebook subscription we have where we load records into the database  
does not have titles coming and going at the whim of the vendor, so  
one of our catalogers manages those records manually.


As a general point of advice, I recommend creating a new bibliographic  
source in config.bib_source and using that as the source for vendor's  
records. If you have more than 1 vendor, then I recommend that you  
create a unique source for each such vendor. This makes it easy to  
delete all the bibliographic records supplied by a given vendor.


If you want something to selectively delete bibliographic records,  
then I don't think there's a good way to do this in Evergreen. AFAIK,  
Vandelay does not delete records. There is a record status field in  
the MARC leader, but Vandelay ignores it. Safariload, linked above,  
actually looks at that field and deletes the matching record(s) by  
bib_source when the vendor has set the status to d.




Thanks for you insights!

Don

Don Butterworth
Faculty Associate / Librarian III
B.L. Fisher Library
Asbury Theological Seminary
don.butterwo...@asburyseminary.edu
(859) 858-2227





--
Jason Stephenson
Assistant Director for Technology Services
Merrimack Valley Library Consortium
Chief Bug Wrangler, Evergreen ILS