Hi All, One other comment on Sands' various approaches. (Thanks for writing these up, Sands!)
I'd be rather hesitant to go with Approach #2 as-is (leave off in 3.0 but make default in 3.1). The reasoning is that 3.1 is really supposed to be a bug-fix only release, based on our new release numbering scheme: https://wiki.duraspace.org/display/DSPACE/RoadMap#RoadMap-ReleaseNumberingScheme I personally think switching around default settings seems to fall outside of the scope of a "bug fix". I'd like to see us make "bug-fix only" releases as minor as possible (so that they can be "easy upgrades" for folks wanting to upgrade quickly to fix bugs). So, that would likely mean also avoiding any significant configuration tweaks (unless the configuration tweak actually does fix a bug in some way). So, that's a long way of saying that I think Sands' "Approach #2" should instead say: "Default to off for 3.0, plan on default on for 4.0 (Fall/Winter 2013)." - Tim On 8/23/2012 12:40 PM, Sands Alden Fish wrote: > Approach #1: Hold off on judgement of this until we have all of the > Discovery contributions merged and running. There have been a lot of > modifications in both the XMLUI & JSPUI side of things. Stability of > these incarnations of Discovery at this point is conjecture. > > Approach #2: Default to off for 3.0, plan on default on for 3.1. If > history is a guide, it won't be too long until we have a 3.1 bug fix > release out. This would allow us to see what kind of stability we get > over the long-term (month++) and iron out any bugs. > > Approach #3: Caution be damned, just enable the thing and trust that > the test-a-thon will catch anything important. (Since architectural > components are being introduced as part of this feature (Solr and new > code that interacts with it) I tend to not favor this approach (IMHO) > because test-a-thon work-overs don't tend to shake out up-time stability > issues, i.e. cumulative bugs that appear only after a resource leak or > the like has been allowed to build up to an error state.) > > This is just off the cuff. What are some other approaches or thoughts? > > > -- > sands fish > Senior Software Engineer > MIT Libraries > Technology Research & Development > sa...@mit.edu <mailto:sa...@mit.edu> > E25-131 > > On Aug 23, 2012, at 1:16 PM, Tim Donohue wrote: > >> Hi All, >> >> This topic came up in yesterday's Developers Meeting, and we all felt it >> worth posting to the dspace-devel list for feedback. >> >> Question: Should Discovery (Solr search/browse) be enabled by default in >> 3.0? >> >> == What would this mean? == >> >> It'd mean that Discovery faceted search/browse (backed by Solr) would be >> the default search/browse interface in 3.0. Users would still be >> welcome to disable Discovery and use the Legacy Search & Browse >> mechanism (backed by Lucene & the database), and we'd provide clear >> instructions on how to do so. >> >> Discovery could be enabled by default for just XMLUI or for both XMLUI & >> JSPUI (see below for more). >> >> == Some possible "Pros" == >> >> * Discovery has been around since 1.6 (for XMLUI) and is becoming much >> more mature >> >> * In 3.0, Discovery will be getting even more exciting features, >> including "search snippets", "hit highlighting", "more like this" >> recommendations, etc. See this JIRA ticket for more details & >> screenshots: https://jira.duraspace.org/browse/DS-1229 >> >> * Also, there is a high probably that in 3.0, Discovery will also be >> available for the JSPUI. (Please note this hasn't officially been >> decided, but the work looks promising so far based on early feedback.) >> This work is being done by CILEA and is described at: >> https://jira.duraspace.org/browse/DS-1217 >> >> == Some possible "Cons" == >> >> * The JSPUI + Discovery work is still very "young". This may mean we'd >> want to closely consider whether Discovery is ready to enable by default >> for JSPUI. >> >> * Discovery does require the DSpace "solr" web application to be >> installed/enabled in Tomcat. This is a separate webapp which sits >> alongside "xmlui" and "jspui". So, if we enable Discovery by default, we >> need to make clear in the Documentation that the "solr" webapp is needed >> to make the XMLUI and/or JSPUI run properly. >> >> >> What do you think? Is this worth considering for 3.0? Would you like to >> see Discovery enabled by default or should we keep it disabled by default? >> >> - Tim >> >> -- >> Tim Donohue >> Technical Lead for DSpace Project >> DuraSpace.org >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Dspace-devel mailing list >> Dspace-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
