Ping Xie

> I think CLUSTER SHARDS is a client-oriented command (as opposed to an administrative command), and I don't see clients' value in getting a shard-id. It may not do much...

@zuiderkwast is spot-on. Replicas are unaware of the migration today. With #10517, this scenario can be supported. The simplest form of redirection could have the source replica redirecting the request...

for 7.2.4 RC1 >We will introduce 2 new info fields I would suggest we move these two new info fields (server_version/server_name) to RC2, where we will close on the compat...

Let me be explicit and make sure we are on the same page > 1.We will build with the following symlink that map to corresponding redis artifacts. Agreed. Here is...

I think the following should be out of RC1. Others look great to me (file names will be symlinked) - ABI/API compat (RedisModule/Lua) // RC2 - Logs and client output...

I think the two RC3 items can be pulled into RC2 since we will be aliasing them. All of your RC2 proposals though sound like a major release thing. For...

> > [adding two new info fields] is a NO for me > > I need to understand why this is a blocker. The reason given (counting number of the...

> Oh, I see, you are concerned because people might be _explicitly_ looking for the 2nd and 3rd line. Would it alleviate the concern if we placed them at the...

Yeah I think we should get the feedback from the release candidate. I agree with "redis.conf being the best documentation for the config". I see little/no operational value in redis.conf...

The way I see it, the problem with `CLUSTER SHARDS` is that it mixes both "configs", cluster topology in this case, and "states" information in the output, such as `replication...