While reviewing, https://github.com/redis/redis/issues/12873, it became clear that there were multiple specific "discussion" threads that were hard to follow because issues don't have good nesting. This is contrast to https://github.com/redis/redis/pull/10875/files, which was much easier to follow the conversation for since most of the specific issues had their own threads.
https://github.com/redis/redis-rcp Used to exist in the past, but has mostly been ignored since Salvatore left. I would primary like us to consider reviving that, and then committing the "accepted" proposals so that we have references for larger implementations.
Current recommended approach
Revive https://github.com/redis/redis-rcp and have people submit PRs to that repo. RCPs will be accepted when we directional approval to accepting an implementation of the proposal (a weak binding vote of confidence for the feature, we might change our mind later), but they will be marked as drafts. Once something is finalized, it will be marked as final.
Comment From: oranagra
i agree. it's much easier to conduct some discussion in PRs, and also incrementally review spec changes and be sure what we actually agree on (when a commit was added). that's what we recently had with the cluster spec, despite not being in the redis-rcp repo, and not being merged, i think worked ok (discussion wise).
I'm not sure it matters that much in which repo that PR and discussion happens, in any case, merging the PR with the spec doesn't have any actual impact until the code is implemented and merged, and it's likely that the spec will later be neglected (unlikely that we'll keep updating it as the code evolves). so i'd argue that it's more convenient to conduct these in the redis repo, but i also don't mind reviving the other repo for that.
p.s. another option is to convert (can be done retroactively) the issue into a discussion, that also supports multiple threads. maybe in some cases this is more convenient since you don't need to prepare a draft spec for people to comment on.
Comment From: madolson
p.s. another option is to convert (can be done retroactively) the issue into a discussion, that also supports multiple threads. maybe in some cases this is more convenient since you don't need to prepare a draft spec for people to comment on.
I've historically not liked discussions, but I could probably get used to them.
I'm not sure it matters that much in which repo that PR and discussion happens, in any case, merging the PR with the spec doesn't have any actual impact until the code is implemented and merged, and it's likely that the spec will later be neglected (unlikely that we'll keep updating it as the code evolves). so i'd argue that it's more convenient to conduct these in the redis repo, but i also don't mind reviving the other repo for that.
I vaguely remember we didn't want to merge the cluster spec into this repo, even though I wish we would have to sort of indicate we were done "discussing" it and we'll implement against it, and keep it up to date as needed. The best way IMO, to keep it up to date would be to keep it in this repo, so changes to the spec could be updated in the same PR. So, I guess I'm inclined to also say let's create a folder tree in this repo for RCPs.
Comment From: oranagra
as i argued, nothing is final until it's implemented, so merging the spec to the repo (and then not getting to implement it) seems wrong to me. same as merging it, implementing it, and then not bothering to update it as the implementation evolves. that's why i argue that it doesn't really matter if we merge it or not. the only benefit of merging it (other than the symbolic statement that it's final), is that other PRs can be made to update it (by a different person than the original author). all of this leads me to think that a separate repo is better than messing this repo (same as what you mentioned about excessive CI cycles). i suppose that for some "projects" a GH discussions are better, than a PR in the other repo. maybe it depends on the complexity and maturity level. i.e. maybe one would should start as an issue / discussion, and then become a spec PR when mature enough.
Comment From: madolson
as i argued, nothing is final until it's implemented, so merging the spec to the repo (and then not getting to implement it) seems wrong to me.
But there is at least agreement on the plan. I guess let me ground the discussion with an example. With cluster v2, a bunch of stuff is still dangling as future improvements. How should we update the status? Have someone else post comments on top of that PR? Have one of the maintainers update Uri's branch? Having it checked in allows people to submit PRs to update it as you mentioned, and I think that is significant.
all of this leads me to think that a separate repo is better than messing this repo (same as what you mentioned about excessive CI cycles).
I agree, let's assume this is the defacto recommendation. For all future commenters I added a suggestion to the top comment.
Comment From: madolson
@yossigo @itamarhaber @soloestoy Do you guys have any concerns with me reviving redis-rpc? I'll migrate the cluster-v2 RCP there and submit a PR making the documentation changes here .