+1 (non-binding) On the scope question raised by Aleksandr and Dmitry, I'd borrow the definition from the Kafka KIP process [1]. It lists the public interfaces explicitly, separates them by how strict the review should be, and says what is not public.
For Ignite it could look like this: - Strictest review: client and internode protocols, data formats on disk. - Public API: every class published in the Ignite Javadoc. The build already excludes org.apache.ignite.internal.*, so the boundary already exists. - Lighter review, usually covered by the feature's IEP: configuration properties, metrics and system views, control.sh commands. - Not public: log messages and console output. Kafka also expects the effort to match the change: a small change needs a couple of paragraphs, a large one a design discussion. That answers the concern that every API tweak becomes a heavy process. [1] https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals ср, 7 окт. 2026 г. в 21:05, Kirill Tkalenko <[email protected]>: > It sounds like a good idea to discuss it. >
