Sorry for spamming. More comments: 4. We must decide and fix RFC identity in commit message when required. 5. We must decide and track RFCs in different statuses: implemented/rejected/in discussion.
пт, 30 окт. 2026 г. в 15:14, Nikolay Izhikov <[email protected]>: > > +1 > > I have a couple of comments. > > 1. Let's use increasing numbers for RFC identification. First RFC will > be 1, second - 2 and so on. > 2. RFC MUST NOT Have ticket link as required element. Moreover, I > think ticket links must be omitted when possible. > 3. We must have RFC-0 to fix RFC structure. > > > > > > > пт, 23 окт. 2026 г. в 21:59, Anton Vinogradov <[email protected]>: > > > > Hi all, > > > > Following our discussion [1] and today's call, I'd like to put the > > following proposal to a vote. > > > > Let's use RFCs for public API changes, keeping them as Markdown files in > > the Ignite repository and reviewing them through pull requests instead of > > creating IEPs. Apache Hudi [2] and TiDB [3] are good examples of this > > approach. > > > > Changes to the public API would need to be covered by an RFC approved by at > > least three Ignite committers before the code is merged. > > > > The first RFC will define what we consider the public API and how the > > process works in detail. We'll discuss and approve that separately; this > > vote is about agreeing on the approach and the three-committer requirement. > > > > The vote will be open for at least 72 hours. > > > > [ ] +1 — Agree > > [ ] 0 — Neutral > > [ ] -1 — Disagree (please explain) > > > > Thanks! > > > > [1] https://lists.apache.org/thread/cfrpdv9t8dq05ghc7dyjppst4m7nd28f > > [2] https://hudi.apache.org/contribute/rfc-process/ > > [3] https://github.com/pingcap/tidb/blob/master/docs/design/README.md
