dsmiley commented on PR #12306: URL: https://github.com/apache/lucene/pull/12306#issuecomment-1553126457
Veto's are serious business, _balancing_ harm to the project & users against the benefit the change brings to both. Thus the change needn't be perfect in every possible way but needs to be a net positive. I hope those using their veto powers weigh the practical upside to this change. The upside / reason for this change has been expressed by users very well so I don't plan to repeat that. Please elaborate on your "trappy" argument, Nick. A user is trapped into setting this somehow or what bad thing happens? Of course if they find the performance to be slow then they have it coming to them. There are plenty of ways to have slow indexing and OOMs, as I'm sure you all appreciate :-). I don't see why the Lucene release timeline matters. This PR aims to improve the Lucene we have today in a simple way, even if new/exciting changes are happening. Even if some new codec were to suddenly appear with a higher limit, why veto this improvement to this codec? Please keep this PR discussion focused on configurability and not other topics like wether the default number of dimensions should change, to include benchmarks. It won't change in this PR. The dev list would be a good forum for that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
