[
https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178409#comment-17178409
]
Noble Paul edited comment on SOLR-14680 at 8/16/20, 1:14 AM:
-------------------------------------------------------------
{quote}Excuse me? that's the whole point of 9.0.
{quote}
You got it all reverse
Major releases are not for introducing fresh features. Major releases are where
we are allowed to break backward compatibility. It is where we remove code .We
slowly build new features in minor releases as "experimental" . None of them
are going to be perfect. But we iterate over time and it gets to a point where
they are good enough where we can deprecate old features and eventually remove
them.
The biggest mistake we have been doing till now is we make kitchen sink
APIs/classes all over and they just stick around. Let's not repeat the same
mistakes
{quote}I'm not sure there's enough manpower dedicated to fully do this
refactoring both in 9.0 and in 8x
{quote}
You know what is the biggest challenge today? No commits to master can be
cherry-picked to branch_8x. The reason is that the code has diverged
significantly and no commits are compatible across master/8x. This makes
development in Solr extremely difficult. We do not have enough manpower.
{quote}eg. arbitrary collection or shard properties, or shard and replica
state.
{quote}
Again you have it reverse.
I did it on purpose.
We shouldn't try to put all methods attributes in one go. This is where we went
wrong in all the previous attempts. I could have added all possible methods in
these classes. It's pretty easy. I start with a basic scaffolding where we can
start with. The objective is to build minimal APIs and work with it . We open
new PRs and add new methods to our existing interfaces. In software, it's easy
to add things and extremely difficult to remove things.
These interfaces are experimental. If you wish to have them fully built &
usable over the next 6 months we need to do a few things
* We should have more discussions around whether a new method should be added
or not. In the beginning we feel like we need everything. Look at DocCollection
class.
* This can only be achieved by trying to cut code over to use the new APIs and
have discussions over what is good and what's bad
Let me put it bluntly. Solr code is badly organized. It was never planned or
built with minimalism in mind. Nobody can make sense of what is what. I want
new devs to read our public APIs and understand the system
If I cannot build these in parallel in both branches , It's going to be a huge
task. I have 2 options
# Do this in parallel in both branches. We add more methods to these classes
or even more interfaces with proper discussion
# Revert this from both the branches and I'm planning to abandon the entire
"clean-api" initiative. Because I clearly know that it is not achievable in
this community.
was (Author: noble.paul):
{quote}Excuse me? that's the whole point of 9.0.
{quote}
You got it all reverse
Major releases are not for introducing fresh features. Major releases are where
we are allowed to break backward compatibility. It is where we remove code .We
slowly build new features in minor releases as "experimental" . None of them
are going to be perfect. But we iterate over time and it gets to a point where
they are good enough where we can deprecate old features and eventually remove
them.
The biggest mistake we have been doing till now is we make kitchen sink
APIs/classes all over and they just stick around. Let's not repeat the same
mistakes
{quote}I'm not sure there's enough manpower dedicated to fully do this
refactoring both in 9.0 and in 8x
{quote}
You know what is the biggest challenge today? No commits to master can be
cherry-picked to branch_8x. The reason is that the code has diverged
significantly and no commits are compatible across master/8x. This makes
development in Solr extremely difficult. We do not have enough manpower.
{quote}eg. arbitrary collection or shard properties, or shard and replica
state.
{quote}
Again you have it reverse.
I did it on purpose.
We shouldn't try to put all methods attributes in one go. This is where we went
wrong in all the previous attempts. I could have added all possible methods in
these classes. It's pretty easy. I start with a basic scaffolding where we can
start with. The objective is to build minimal APIs and work with it . We open
new PRs and add new methods to our existing interfaces. In software, it's easy
to add things and extremely difficult to remove things.
These interfaces are experimental. If you wish to have them fully built &
usable over the next 6 months we need to do a few things
* We should have more discussions around whether a new method should be added
or not. In the beginning we feel like we need everything. Look at DocCollection
class.
* This can only be achieved by trying to cut code over to use the new APIs and
have discussions over what is good and what's bad
Let me put it bluntly. Solr code is badly organized. It was never planned or
built with minimalism in mind. Nobody can make sense of what is what. I want
new devs to read our public APIs and understand the system
If I cannot build these in parallel in both branches , It's going to be a huge
task. We have 2 ways to do this
# Do this in parallel in both branches. We add more methods to these classes
or even more interfaces with proper discussion
# Revert this from both the branches and I'm planning to abandon the entire
"clean-api" initiative. Because I clearly know that it is not achievable in
this community.
> Provide simple interfaces to our concrete SolrCloud classes
> -----------------------------------------------------------
>
> Key: SOLR-14680
> URL: https://issues.apache.org/jira/browse/SOLR-14680
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Minor
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> All our current implementations of SolrCloud such as
> # ClusterState
> # DocCollection
> # Slice
> # Replica
> etc are concrete classes. Providing alternate implementations or wrappers is
> extremely difficult.
> SOLR-14613 is attempting to create such interfaces to make their sdk simpler
> The objective is not to have a comprehensive set of methods in these
> interfaces. We will start out with a subset of required interfaces. We
> guarantee is that signatures of methods in these interfaces will not be
> deleted/changed . But we may add more methods as and when it suits us
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
