Hi all, For now, I’m -1 on the proposal in its current form.
My earlier questions remain unresolved. We have not yet agreed on clear criteria for when an IEP is required, what level of detail makes it ready for approval, or how we determine that its implementation is complete. Even the scope of “public API and supported behavior” is still open. This makes it difficult for contributors and reviewers to apply the proposed rules consistently. If these decisions ultimately rely on common sense, I think we can exercise that judgment through ordinary discussion on the dev list. We can assess a proposal’s value, feasibility, and compatibility implications there, and decide whether it needs a detailed IEP. Requiring three explicit approvals for every change within such a broad scope seems too much. The examples raised concern work that started years ago, and some already followed an IEP-based process. Before introducing additional approval requirements, we should understand what went wrong and how those requirements would have prevented it. We also do not currently have many wishers of contributors proposing new features. Adding procedural barriers could discourage the participation we need. I would prefer to keep the process lightweight: start with a dev-list discussion and agree on the documentation and review needed for the particular change. We should welcome community initiatives and help contributors develop their proposals without making them navigate a complex process whose rules are still unclear. On Wed, Oct 7, 2026 at 8:20 AM Dmitriy Pavlov <[email protected]> wrote: > 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 > > > > > > -- Vladislav Pyatkov
