[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795932#action_12795932
]
patrick o'leary commented on SOLR-1602:
---------------------------------------
1) I agree that Solr needs shorter release cycles, and let me add to that, a
firm road map, that is more community driven.
* Tasks are tackled by trying to solve the hardest parts, rather than iterative
development.
* Users don't see benefits, just patches, most of which won't apply after a few
weeks or months.
*
2) Solr is still young
* it's only been around 4 years.
* It can afford changes, this one is minor, it's config driven, solrconfig
(e.g. where only experts dare) rather than schema-
{code}
<queryResponseWriter name="xml"
class="org.apache.solr.response.XMLResponseWriter" default="true"/>
<queryResponseWriter name="json"
class="org.apache.solr.response.JSONResponseWriter"/>
<queryResponseWriter name="python"
class="org.apache.solr.response.PythonResponseWriter"/>
<queryResponseWriter name="ruby"
class="org.apache.solr.response.RubyResponseWriter"/>
<queryResponseWriter name="php"
class="org.apache.solr.response.PHPResponseWriter"/>
<queryResponseWriter name="phps"
class="org.apache.solr.response.PHPSerializedResponseWriter"/>
<queryResponseWriter name="xslt"
class="org.apache.solr.response.XSLTResponseWriter">
{code}
3) We still don't identify who consumers of Solr are
* The end user, where search quality, and performance makes a difference
* The implementer, who downloads, installs, updates solr
* The experts, who customize solr
* The extender, who develop using Solr as a framework (embedded, and as a
webapp)
This change affects the last 2, experts, and extenders, and in a positive way.
The last two classes of users are continuously being affected by development,
just think of
packages being moved around in solr/common, solr/java, solr/solrj etc..
One compromise would be to have releases as sprints, say a minor release every
quarter, and major every 1 to 2 years?
Where you can deprecate something with the resolution of eliminating it before
2 minor releases. (6 months)
> Refactor SOLR package structure to include o.a.solr.response and move
> QueryResponseWriters in there
> ---------------------------------------------------------------------------------------------------
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers
> Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
> Reporter: Chris A. Mattmann
> Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt,
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are
> curiously located in the o.a.solr.request package. Not only is this package
> getting big (30+ classes), a lot of them are misplaced. There should be a
> first-class o.a.solr.response package, and the response related classes
> should be given a home there. Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
