Hi,
My comments below too

2009/10/30 Demian Katz <demian.katz@villanova.edu>

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 import-marc.sh 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 import-marc.sh, but this was to fix a Unix-only bug -- the Windows version should be unaffected.

No I didn't - i just noticed the different modified dates and made a silly assumption. Well, that's one less thing to worry about ;)
 

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.

Removing the custom search handlers will certainly help avoid confusion.

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!

Yes, I was impressed with the level of inline documentation in yamlspec (also in SearchObject.php). Again I was thinking more of the first-time user who might give up in frustration or confusion before they get to it - so, yes, I was thinking more of the Wiki. Even a short "What's new in RC2" page might help with this.
 

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.

Great
 

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!


Yes, I'll look at these.

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.

I can take this on for Windows

- Some pages that currently talk about changing code (i.e. http://www.vufind.org/wiki/searches_customizing_tuning_adding) 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.

Cheers,
Eoghan