Then I switch my vote for issue 3 to "A) Sounds good to me"


2009/11/2 Greg Pendlebury <>

>>>> I think the dates you suggest sound realistic, but since I'm not doing the core development I'm wary about commiting those that are to a date. In particular, I think we should double check the dates with Greg since he doesn't have a vote on this list.

>> Regardless of load, though, Greg's input is definitely welcome in this conversation.  I'm pretty sure he lurks on this list, so hopefully we'll hear from him sooner or later.


The dates sound reasonable to me. I’ve mentioned this to Demian already, but locally my time is mostly devoted to our test site at the moment. That just means my work on the trunk is limited to:

a)      Tickets I’ve already started/accepted (like the search object).

b)      New issues our local group identifies that are required to align our test site with the trunk.


The overall goal is for our test site to be an easily patchable version of trunk. And by patchable I mean branding and business logic tweaks, not major features. So the timelines for RC2 are good for us, because that means our test site will be on RC2 all the sooner.


Greg Pendlebury
Electronic Services Officer (Systems Team)
Division of Academic Information Services
University of Southern Queensland
Phone: +61 7 4631 1501
Fax: +61 7 4631 1841

From: Demian Katz []
Sent: Saturday, 31 October 2009 3:34 AM
To: Eoghan Ó Carragáin
Subject: Re: [Vufind-admins] Admin Votes: SolrMarc Upgrade, Single-File Configuration, Release Date


My comments are embedded below in blue.  Sorry if this is not the most readable format -- I can't seem to persuade Outlook to quote emails the way I want it to.

ISSUE 1: New SolrMarc Version
A) Yes, do it now.

I've re-indexed using your patch and it worked fine, so there doesn't appear to be any loss of functionality (oh, actually, I don't think your patch included an updated windows batch file, so used cygwin with the *.sh. This should be updated before a commit).

No changes should be needed to or import-marc.bat in order to work with the new version of SolrMarc.  Did you try the existing import-marc.bat under Windows?

Note that I did recently make a change to, but this was to fix a Unix-only bug -- the Windows version should be unaffected.

ISSUE 2: Single-File Search Configuration
C.) Wait for more discussion.

I think a single file is the right way to go, but I think it could do with some more discussion & documentation. For new implementors, experimenting with solrconfig.xml is more accessible (they may already have solr experience, more likely to be comfortable with xml than yaml etc) and has Solr documentation.

One thought that might help alleviate this concern -- presently, the patch removes all of the custom search handlers (Author, Title, etc.) and always uses the standard handler for dismax and non-dismax queries.  However, perhaps it would be better to have two handlers defined in solrconfig.xml -- standard and dismax.  A user could then assign global default settings (like "mm") in solrconfig.xml on the dismax search handler…  OR they could override them for individual search types through a new mechanism in the YAML.  Seems like the best of both worlds.

Also, until parameters like "mm" are in the yaml, this will reduce functionality (and may have back-compatibility issues for some installs?)

This is what I alluded to when I mentioned Till's suggestion -- I can work this into the existing patch if you want proof that it can be done before we commit anything, but I really don't think it should be difficult to add as an immediate post-patch follow-up.

If we want this in for RC2, then we need it documented, which leads me on to...

The documentation in the YAML file itself is pretty exhaustive (though I'm sure there's room for improvement).  We'll obviously need to update the Wiki in several places to point out the existence of this resource, however!

ISSUE 3: RC2 Release Date
B.) Let's discuss further... (doesn't have to be a long discussion ;) )

I think the dates you suggest sound realistic, but since I'm not doing the core development I'm wary about commiting those that are to a date. In particular, I think we should double check the dates with Greg since he doesn't have a vote on this list.

I think we can set a date without putting an unreasonable burden on Greg.  As far as I can tell, his remaining RC2 commitment (based on JIRA tickets, anyway) boils down to the aspect of VUFIND-5 that he recently brought up on the vufind-tech list (URL truncation problems caused by super-long advanced searches).  I think there's a good chance this will be sorted out fairly soon, and even if it isn't, it's a small enough edge case that I think we can let it slide to 1.0 if we have to.

Regardless of load, though, Greg's input is definitely welcome in this conversation.  I'm pretty sure he lurks on this list, so hopefully we'll hear from him sooner or later.

Also, what if anything do we want/need to do for non-code matters. Looking at the outstanding RC2 tickets, I can't see much I can contribute since most are well-progressed. However, I'm very willing to give some time in the run-up to a release: Is there documentation that needs updating? Are there elements that could do with some more structured testing? Do we want to publicise the release beyond our own lists and website etc.?

As far as coding goes, if you're able to finish up the CSS-related problems, that alone would be a great contribution!

For non-coding matters, a few thoughts:

1.) The RC1 -> RC2 upgrade script (VUFIND-132) needs testing, refinement and integration into the trunk.  If you want to test it out with a copy of your local data, or if you want to contribute to the discussion currently taking place in the comments of the JIRA ticket, that would be welcome.

2.) The Wiki needs updating in a lot of places.  A few specific thoughts:

- We should retest all the install docs with RC2 code.  I know the Windows documentation needs to be simplified to account for the batch files that reduce the complexity of installation and other tasks.  I'm not sure if other platforms are affected.

- Some pages that currently talk about changing code (i.e. should be revised to explain the new configuration files that simplify the process.

- We need to figure out a way to update pages to reflect RC2 without losing important information needed by RC1 users.  I'm not sure how best to achieve this.  One simple solution would be to create a link at the top of the page saying "This applies to RC2 -- click on this link to see the RC1 version" and then point the link in the message back to the last RC1-related version in the Wiki.  Of course, the problem with this is it freezes the RC1 data in place so that it can no longer be easily edited.  Another, more complicated option is to create *_RC1 versions of existing pages for historical purposes, though that is likely more work than it's worth.

- Perhaps we should add a JIRA ticket about updating documentation -- this is an important part of our to-do list, after all.  I'll hold off until after further discussion, though.


2009/10/30 Demian Katz <>

We've had some good discussions and made significant progress this week, but I'm calling a vote on a few issues to make sure the whole admin group gets a chance to comment before action is taken.




ISSUE 1: New SolrMarc Version


So far, a few people have tested out my demian_solrmarc branch that updates VuFind to use the new SolrMarc binary.  Reaction so far seems positive.  Are we comfortable with merging this into the trunk?


A.) Yes, do it now.

B.) No, don't do it.

C.) Wait for more testing.




ISSUE 2: Single-File Search Configuration


I posted a patch this week that moves Dismax settings from solrconfig.xml to searchspecs.yaml.  Till suggested adding support for other Dismax-related settings in the YAML file, which shouldn't be a problem.  Do we want to apply this to the trunk?


A.) Yes, do it now.

B.) No, don't do it.

C.) Wait for more discussion.




ISSUE 3: RC2 Release Date


We're getting really close to finishing up all the RC2 issues in JIRA.  I think we should be able to set a firm release date somewhere before the end of the year.  The biggest complicating factor from my perspective is the fact that I'm going to be on vacation (and most likely away from frequent Internet access) from November 21 through December 2.  If last-minute work is needed, I won't be able to participate very effectively during that period -- I'll be lucky if I can even check my email.


For a smooth release, we should probably set a couple of dates -- one as a target to complete development of RC2 and generate a tag in SVN marking the official RC2 release, and the next to actually release it to the public.  The time between the two dates can be used to test the stabilized code in the tag (fixing only critical bugs), update documentation, etc.


Here's a fairly arbitrary suggestion:  how about we aim to tag RC2 by Friday, December 4th at the latest (and do it earlier if all JIRA tickets get closed).  We then aim to release on Monday, December 14th.  This gives us at minimum a full work week for updating documentation and last-minute testing (longer if we get done early, which seems probable).  The release date is also far enough in advance of the holidays that we can be responsive to feedback about the release before many institutions go on break.


A.) Sounds good to me!

B.) Let's discuss further...


(I don't honestly expect everyone to vote to accept these preliminary dates…  but I figure it doesn't hurt to call a vote and get the debate going).




I'll hold off on officially casting my votes until I've seen some other responses.  Since I'm calling the vote and have probably biased it enough already simply by writing this message, I might as well give everyone a chance to change my mind in case I'm making any bad assumptions.


- Demian

Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
Vufind-admins mailing list


This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.

The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.

The University of Southern Queensland is a registered provider of education with the Australian Government (CRICOS Institution Code No's. QLD 00244B / NSW 02225M)