jorgecarleitao edited a comment on pull request #422: URL: https://github.com/apache/arrow-datafusion/pull/422#issuecomment-848039362
So, a question that I would like to bring before committing to RFCs. I see two ways of approaching this: 1. the delta approach: each RFC may change previous RFCs, becoming the "latest" or a mixture of 2. the specification approach: each change is a PR, and the combined result is the new "specification" Both have benefits and downsides. My opinion is that we should not use the RFC approach, and instead work under the "specification" model. The reason is that, in my opinion, RFCs are hard to follow because they were made in a specific moment in time and no longer updated. If updated, there is a new RFC that does that, which requires some form of consolidation (e.g. RFCs have the term "amends", "superseded by", "revoked", PEP also). My opinion is that, with PRs, git history and git blame, there is no need to store the "deltas" (RFCs) in the repository itself, and we should instead offer the consolidated, up-to-date picture of the specification. This was the rational of the original issue, at least. TL;DR: an RFC is a "delta", the specification is the "state". An RFC/PR brings the state from the previous state to a new state. IMO we should have the specification on the repo and use PRs to track deltas (as opposed to having the deltas themselves in the repo) -- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
