Thanks Gustavo and Sai, Gustavo, I agree. For bw-compatible changes and extensions, we should use common sense to decide whether a dev@ discussion is warranted. A short discussion is the safer choice when the impact or user-facing semantics are not obvious, but it should not be a mandatory process step for every optional parameter for example.
Sai, I see a FLIP primarily as a record of the design at a specific point in time. Once a feature is delivered and others build on it, the design can naturally evolve through review and operational experience. The current implementation is ultimately the source of truth, alongside its user-facing documentation. Requiring later adjustment(s) to be reflected in the original FLIP would create an unrealistic maintenance burden and would blur its role as a historical design record. If we all agree, I will incorporate the agreed guidance into the wiki: - Use normal PR review for non-API changes. - Use judgment for backward-compatible API extensions and start a dev@ thread when the change warrants broader input. - Require the established FLIP process for bw-incompatible changes or changes that revisit a central design decision. WDYT? Best, Ferenc On Friday, October 2nd, 2026 at 14:45, Krishna Sai <[email protected]> wrote: > Hi Ferenc, > > A precedent that may be useful, and a question. > > FROM_CHANGELOG's error_handling is this exact situation. FLIP-564 specifies > invalid_op_handling with FAIL | LOG | SKIP, which came out of the > DISCUSS thread. > PR #27994 changed it to error_handling with FAIL | SKIP during review, on > forward-compatibility grounds, and the review says explicitly that this was > not > in the FLIP. That is what went into master in April, for 2.4.0. > > So it was settled in review without a dev@ thread, which seems to support the > common-sense reading already suggested in this thread. What did not > follow is the > FLIP page: it still carries invalid_op_handling and the three options, > unedited > since 17 March. That is the part I would find most useful in a rule - not the > discussion level, but who brings the FLIP back in line once the > decision is made. > The wiki asks for the page to be updated after the vote to record the > result, and > says nothing about afterwards. > > Best, > Sai Krishna Sepuri > > On Thu, Oct 1, 2026 at 7:43 PM Gustavo de Morais <[email protected]> > wrote: > > > > Hi Ferenc, > > > > Thanks for kicking off the discussio for this. We'll continuously add new > > built-in PTFs and some guidelines around this will definitely be useful for > > future discussions. > > > > I agree your first and last point. Regarding the second one, I'd be fine > > with both optional parameters being added with or without a discussion. > > Common sense is required depending on the change, and a short discussion is > > always the safer option, as we're doing with TO_CHANGELOG. New required > > parameters ones are breaking changes, thus fall into the > > backwards-incompatible changes bucket and require a mailing list > > discussion. > > > > Kind regards, > > Gustavo > > > > > > On Thu, 1 Oct 2026 at 15:28, Ferenc Csaky via dev <[email protected]> > > wrote: > > > > > Hello devs, > > > > > > While reviewing a proposed change to TO_CHANGELOG [1], we ran into a > > > broader > > > process question: what level of community discussion should we require for > > > adjustments to the built-in process table functions (PTFs) after their > > > original > > > FLIP has been approved? > > > > > > The specific change is additive and backward-compatible, but it would add > > > a > > > new user-facing parameter. The question is therefore not limited to this > > > function: as we gain operational experience with the first built-in PTFs, > > > we > > > should have a shared and predictable rule for similar changes. > > > > > > My initial thought is: > > > > > > - Implementation changes, documentation fixes, and bug fixes that do not > > > change the public API or its intended semantics can proceed through the > > > normal PR review process. > > > - A user-visible API or semantic change to a built-in PTF, including an > > > additive optional parameter, should at least have a short mailing list > > > discussion. > > > - Backward-incompatible changes, or changes that revise a decision central > > > to > > > the original FLIP should follow the normal FLIP process. > > > > > > The TO_CHANGELOG design itself is intentionally being discussed > > > separately. > > > > > > Best, > > > Ferenc > > > > > > [1] https://github.com/apache/flink/pull/29102 > > > >
