[
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050936#comment-14050936
]
Mark Miller edited comment on SOLR-5473 at 7/3/14 12:59 AM:
------------------------------------------------------------
bq. Just because of the fear of the unknown?
For fear of the hellish API's that devs and users will be stuck with. I'm sorry
if I was not clear about that. And for fear of what you are affecting that you
don't understand. To do this kind of work and not add or mess with many tests
looks very scary from where I am sitting. We need more effort on stabilizing
and investigating existing test fails, more work on adding tests for missing
and changed areas - much more than we need this kind of unstabalizing change
when the API's are half baked and detrimental to the code base if people
starting building on them.
bq. The point is I raised this question before
And I've talked about it before - probably more than once. There are tradeoffs
in the approaches. I told you at a minimum that I would certainly be open to
have the option to do selective. And that if you wanted to change to selective
by default, it seems that you should have to specifically investigate and argue
that the change is better by spelling out the nuances of the change, the
benefits and the loses, etc. I didn't say it could not be done, I said it did
not seem like we came to a consensus.
It feels like everything we have discussed from the start and I had issues
with, you have essentially done it all as you planned anyway, and anytime I
object, you go back and do some cosmetic changes and roll back the same thing.
You tell me, the big stuff you want changed, too hard, impossible, the small
stuff, done and done (with half not done, like all the external mentions still
there).
There is no consensus IMO, not until I'm convinced by more voices that I'm
smocking crack, and a vetoed commit cannot be committed again until a veto is
withdrawn.
was (Author: markrmil...@gmail.com):
bq. Just because of the fear of the unknown?
For fear of the hellish API's that devs and users will be stuck with. I'm sorry
if I was not clear about that. And for fear of what you are affecting that you
don't understand. To do this kind of work and not add or mess with many tests
looks very scary from where I am sitting. We need more effort on stabilizing
and investing existing test fails, more work on adding tests for missing and
changed areas - much more than we need this kind of unstabalizing change when
the API's are half baked and detrimental to the code base if people starting
building on them.
bq. The point is I raised this question before
And I've talked about it before - probably more than once. There are tradeoffs
in the approaches. I told you at a minimum that I would certainly be open to
have the option to do selective. And that if you wanted to change to selective
by default, it seems that you should have to specifically investigate and argue
that the change is better by spelling out the nuances of the change, the
benefits and the loses, etc. I didn't say it could not be done, I said it did
not seem like we came to a consensus.
It feels like everything we have discussed from the start and I had issues
with, you have essentially done it all as you planned anyway, and anytime I
object, you go back and do some cosmetic changes and roll back the same thing.
You tell me, the big stuff you want changed, too hard, impossible, the small
stuff, done and done (which half not done, like all the external mentions still
there).
There is no consensus IMO, not until I'm convinced by my voices that I'm
smocking crack, and a vetoed commit cannot be committed again until a veto is
withdrawn.
> Make one state.json per collection
> ----------------------------------
>
> Key: SOLR-5473
> URL: https://issues.apache.org/jira/browse/SOLR-5473
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 5.0
>
> Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-configname-fix.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473_undo.patch,
> ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log
>
>
> As defined in the parent issue, store the states of each collection under
> /collections/collectionname/state.json node
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
