Re: [Vufind-admins] Admin Votes: SolrMarc Upgrade, Single-File Configuration, Release Date

[Eoghan Ó C. <eog...@gm...>]

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

Cheers,
Eoghan

2009/11/2 Greg Pendlebury <Gre...@us...>

>  >>>> 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 [mailto:dem...@vi...]
> *Sent:* Saturday, 31 October 2009 3:34 AM
> *To:* Eoghan Ó Carragáin
> *Cc:* vuf...@li...
> *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 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.
>
> 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.
> 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
>
> 2009/10/30 Demian Katz <dem...@vi...>
>
> 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!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Vufind-admins mailing list
> Vuf...@li...
> https://lists.sourceforge.net/lists/listinfo/vufind-admins
>
>
>  ------------------------------
> 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)
>