Hello, Kirill. > Don't you think that by introducing a stricter development process, we might > increase development time where it isn't necessary?
The point here - we want to improve decisions quality and long term API stability. > 1. You could provide more explanations and examples here. > Take `SELECT FOR UPDATE`, for instance, which was introduced recently. > As I understand it, since this was a change to the public API, the procedure > should have been to create an IEP, go through its full lifecycle, and only > then begin implementation? Yes. > What should be done if problems are found in the current IEP, or something > was overlooked, and it needs to be improved, does that also require a new IEP? Yes. The goal of IEP and voting process is to prevent issues in the API. So, If we spend more time before pinning API then we will prevent future broken changes and complete features removal. > 2. Who will be responsible for verifying that no backward compatibility cases > have been overlooked? IEP author in the first place. Ignite community as an entity that supports project in a healthy state. > What do you mean by "support"? > Who will be responsible for the IEPs and their bug fixes? Nothing changes here. Community is responsible for fixing bugs and improving project. > 3. And how does it differ from the current mechanism? 1. By writing down clear rules what MUST be done with the IEP process: changes in public API and public behaviour (client, disk formats). 2. By enlarging the number of approvals required to change public things. > Have you seen similar practices in other public projects? Yes. Many projects has similar approach: * Kakfa KIPs - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55155994 * Cassandra CEPs - https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/95652201/Cassandra+Enhancement+Proposals+CEP * Spark SPIPs - https://spark.apache.org/improvement-proposals.html * Pyathon PEPs - https://peps.python.org/ to name a few. It is much harder to name a project that allows changing public API with the one approval rather than opposite. вт, 6 окт. 2026 г. в 09:05, Kirill Tkalenko <[email protected]>: > > Hi Anton! > > I am not in favor of increasing formalism or swinging too far in either > direction; doing everything without IEPs, or relying solely on them, both > seem concerning at this stage. > > I would suggest keeping the current approach where major changes or features > require an IEP, while small or minor ones can simply be discussed on the dev > list. > > Don't you think that by introducing a stricter development process, we might > increase development time where it isn't necessary? > > Regarding your points: > > 1. You could provide more explanations and examples here. Take `SELECT FOR > UPDATE`, for instance, which was introduced recently. As I understand it, > since this was a change to the public API, the procedure should have been to > create an IEP, go through its full lifecycle, and only then begin > implementation? What should be done if problems are found in the current IEP, > or something was overlooked, and it needs to be improved, does that also > require a new IEP? > > 2. Who will be responsible for verifying that no backward compatibility cases > have been overlooked? What do you mean by "support"? Who will be responsible > for the IEPs and their bug fixes? > > 3. And how does it differ from the current mechanism? > > 4. Why specifically multiple PRs instead of Jira tickets? > > Have you seen similar practices in other public projects?
