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
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).
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?
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.
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.
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.
parameters like "mm" are in the yaml, this will reduce functionality
(and may have back-compatibility issues for some installs?)
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...
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
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.
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.
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
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.?
far as coding goes, if you're able to finish up the CSS-related problems, that
alone would be a great contribution!
non-coding matters, a few thoughts:
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.
The Wiki needs updating in a lot of places. A few specific thoughts:
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. http://www.vufind.org/wiki/searches_customizing_tuning_adding)
should be revised to explain the new configuration files that simplify the
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 <firstname.lastname@example.org>
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.
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