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 > >
