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
