[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796080#action_12796080
]
Hoss Man commented on SOLR-1602:
--------------------------------
Uh ... ok.
First off: Broad discussions beyond the scope of this particular Jira issue
really don't feel appropriate in the comments -- discussions about Solr's
release cycles, general architecture, roadmaps, targeted user base, etc.
should be on the mailing list where they are more visible.
Second: In trying to catch up with all of the new comments in this issue since
the last time i looked at it, i find myself with very little substantive
comments to add beyond what i already said. i started trying to address some
individual points people have made, but that just felt tedious, so i'll just
make a few comments in general. Hopefully I'll say the same thing in a
different way that will make more sense...
There are very few instances in Solr's history where we have ever (knowningly)
broken backwards compatibility at the "user level" ( config files, request
params, etc...) -- in all of those cases, we tried to provide a simple method
for users who depended on the legacy behavior to restore it with a simple
configure change which was advertised in the upgrade instructions. In every
one of those situations (that i can remember) we *still* had a few users who
got confused/frustrated at the change in behavior. I don't really have the
energy/inclination to go find documentation on all of those situations, but
here's two examples that are fresh in my mind because they just happened last
month when people tried to upgrade to 1.4 and didn't notice the change
regarding the legacy ";" sort syntax...
http://old.nabble.com/Upgrade-from-1.2-to-1.4-to26829388.html#a26829388
http://phatness.com/2009/11/sorting-by-date-with-solr/
I'm not suggesting that we should always strive for 100% back compat in the
configs and the request params and that people should expect identical configs
to always work in every Solr release for hte next 74 years -- but so far, the
only times we've (knowingly) broken existing configs it was when the goal was
to either improve the default behavior, or add additional functionality. I've
got no problem telling 40% of our existing users "you need to add foo=bar to
your config to have it keep working" if it means that the other 60% and every
other new users gets something good out of deal....
....but i see no good reason to break things for a large percentage of our user
base when there is no value add to them in return ... having a (subjectively)
cleaner code base is not a justification for making an upgrade break unless
users edit their configs, or run a script.
If breaking things was the only way to fix some major bug, or add some cool
feature, or saved us 100 man hours of development then i would be completley on
board telling people "sorry, please change this one line." but when keeping
things working takes such little effort, it would be completley irresponsible
to fuck our users over like that -- trivial shit like needing to make a nusance
edit to a config file for no apparent reason is what drives users away and
leaves a bad enough taste in their mouth that they actively trash talk a
product/project as being "unstable"
I honestly can't fathom how having ~10 less files in one directory is worth the
amount of discussion we've already had on this -- let alone the headaches of
all the people this would screw over on upgrading. It's just such a fucking no
brainer to me.
> 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.
