Vladislav, How about having a Zoom call to discuss this properly? I'm pretty sure we'll share a vision of how Ignite can become a top-level project useful for many and many organisations, and you'll change your mind, or we'll find a compromise.
On Wed, Oct 7, 2026 at 5:38 PM Vladislav Pyatkov <[email protected]> wrote: > 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 >
