Hi folks, I agree with most of the points: significant changes should be discussed before merging, and IEPs should explain completion criteria, compatibility implications, and plans for future support.
However, -1 to making three committer approvals mandatory for every IEP. Some of the features mentioned already had IEPs. For example, IEP-37: New query execution engine <https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A%2BNew%2Bquery%2Bexecution%2Bengine> described the Calcite-based engine, including requirements and expected integration steps. We should understand why those plans did not lead to the intended outcomes and how additional approvals would have helped. This proposal would move us from allowing lazy consensus to requiring explicit voting for every change within a very broad scope. My counterproposal is to explicitly allow lazy consensus <https://www.apache.org/foundation/voting.html#lazy-consensus>: announce the proposal on the dev list, give the community time to review it, and proceed if there are no objections. Discussion should be mandatory (like this one), but a fixed number of explicit approvals should not. WDYT? Sincerely, Dmitriy Pavlov P.S. We also need a process that works when community activity is low. Having many committers or PMC members on the roster does not mean that three of them are actively available to review each proposal. Participation changes over time, and attention is spread across different Ignite versions. How would we continue developing a less active version if every such change required three explicit approvals? вт, 6 окт. 2026 г. в 16:07, Anton Vinogradov <[email protected]>: > Thanks everyone involved! > > Nikolay, thanks for your support! > > Kirill, the goal is to create a useful and powerful process instead of > formalism. > > Nikita, > > Could you clarify how API deprecation and removal would be handled? > TBD, let's think about it. > Any proposals? > > Aleksandr, > > do we have a clear definition of "Public APIs or their supported > behavior"? > TBD again. > My goal is to start this change and (maybe) lead it. > I don't know all the answers, let's start with some proposals. > > Dmitry, > > I believe we need to more precisely specify which public API changes > require an IEP > Any. Not a joke. Any public, but the question of what is public is still a > question. > Start case is the disk and communications formats, public Ignite Java API > (not internal classes). > Feel free to add something. > > Vladislav, > > Could we allow revisions to the existing IEP > Sure, common sense is our power. > > What makes an IEP ready for approval, and how do we determine that its > implementation is complete? > Same answer; let's start with common sense and see how it's going. > > Can we automatically flag or block PRs that change public APIs or > behavior requiring an IEP but have no linked IEP? > Hope to know how :) > Let's start with a simple statement and a simple document via the > Developer's Guide page, and take a look. > > On Tue, Oct 6, 2026 at 2:53 PM Vladislav Pyatkov <[email protected]> > wrote: > > > Hi all, > > > > 1. Tying a vote to a specific version of an IEP makes sense. However, > > requiring a new IEP for every correction or refinement seems > excessive. > > Could we allow revisions to the existing IEP, preserving the approved > > version and putting substantial changes through another review and > vote? > > 2. What makes an IEP ready for approval, and how do we determine that > > its implementation is complete? Is a description of the functionality > > with > > explicit completion criteria enough, or is an exhaustive list of > linked > > implementation tickets required? > > 3. How would we enforce this rule during code review? Can we > > automatically flag or block PRs that change public APIs or behavior > > requiring an IEP but have no linked IEP? Or would identifying such > > changes > > remain entirely the reviewers’ responsibility? > > > > > > On Tue, Oct 6, 2026 at 2:17 PM Dmitry Werner <[email protected]> wrote: > > > > > Hi all, > > > > > > +1 overall. > > > > > > I believe we need to more precisely specify which public API changes > > > require an IEP (for example, adding metrics, modifying log messages, > > etc.) > > > so that the rules are unambiguous for everyone. > > > > > > Aleksandr's questions about log messages and internode messages are a > > good > > > illustration of why this clarification matters. > > > > > > On Tue, Oct 6, 2026 at 3:37 PM Aleksandr Chesnokov < > > > [email protected]> > > > wrote: > > > > > > > Hi all, > > > > > > > > > > > > Adding to Kirill's questions: do we have a clear definition of > "Public > > > > APIs or their supported behavior"? To be more specific: > > > > > > > > 1. Are log messages part of the public API? As far as I know, some > > users > > > > build grep scripts on top of Ignite logs. > > > > > > > > 2. Are internode messages part of the public API? Should we create an > > IEP > > > > for a change of the wire protocol (the order of fields in a message, > > for > > > > example)? > > > > > > > > As an example, Hadoop has an explicit compatibility guide [1] which > > > > declares audience (who may rely on it) and stability (how freely it > may > > > > change) for each kind of interface. The two are separate: log output > is > > > > "Public and Unstable" [2], server-server wire protocols are "Private > > and > > > > Stable" by default [3]. Maybe we can add a similar list to the > > proposal? > > > > > > > > > > > > [1] > > > > > > > > > > https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compatibility.html > > > > [2] > > > > > > > > > > https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compatibility.html#Log_Output > > > > [3] > > > > > > > > > > https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compatibility.html#Wire_Protocols > > > > > > > > > -- > > Vladislav Pyatkov > > >
