Again, feature freeze is not about "what was planned", it is a about what is ready. Otherwise, it is completely unplannable when a release would come. Everyone has a pet feature they want to see in. If everyone just makes decisions by themselves and pushes, we can never get anywhere.
Disagreement with the current practice can be raised and discussed. But one sided decisions to just ignore the established rules because of disagreement is not acceptable. That's not how this (or any) open source community can work. If we want to keep building an open and fair community and still release high quality software, we have to be very clear about this. On Thu, Aug 8, 2019 at 5:29 PM Timo Walther <twal...@apache.org> wrote: > Hi Xuefu, > > I disagree with "all those work would be wasted/useless", it would just > take effect 3 months later. > > Regarding "I don't see eye to eye on how and when we had decided a > feature freeze", there was an official [ANNOUNCE] email that targeted > June 28 [1]. I think nobody is super strict about such a date and an > additional day or two but we need to stop merging into a branch to > ensure build stability. > > The Flink community decided on time-based releases some time ago, of > course we could discuss this policy again. But generally speaking we > should release quickly because every release contains nice features that > users are waiting for. The PR in question was not listed in the intial > feature discussion [2] and mentioned for the first time mid/end of June. > > Personally, for the next release, I would prefer to vote on a list of > FLIP topics that qualify for a release (given that they are finished in > time with the expected quality). > > What do you think? > > Thanks, > Timo > > [1] > > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/ANNOUNCE-Feature-freeze-for-Apache-Flink-1-9-0-release-tp29751.html > [2] > > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Features-for-Apache-Flink-1-9-0-td28701.html > > Am 08.08.19 um 15:43 schrieb Xuefu Z: > > Hi all, > > > > I understand the merged PR is a feature, but it's something we had > planned > > and requested for a long time. In fact, at Hive connector side, we have > > done a lot of work (supporting hive udf). Without this PR, all those work > > would be wasted and Hive feature itself in 1.9 would also be close to > being > > useless. > > > > I also agree that feature freeze means something and has its importance. > On > > the other hand, I don't see eye to eye on how and when we had decided a > > feature freeze should be in place. To me, our feature freeze seems to be > > time based. That is, we determine a time by which feature freeze will > > happen, irregardless original feature plan. As a result, this practice > > incurs a great deal of randomness, leaving many planned feature half > baked. > > The question is really about how we balance releasing something in time > > vs releasing something usable. This might be a great chance for us to > > meditate on this topic. > > > > The PR in question is requested by me, and its importance to Hive > connector > > makes me stand by my request. On the other hand, if the PR has anything > to > > improve, I'm all for it. > > > > Thanks, > > Xuefu > > > > On Thu, Aug 8, 2019 at 2:59 AM Timo Walther <twal...@apache.org> wrote: > > > >> Hi Kurt, > >> > >> I posted my opinion around this particular example in FLINK-13225. > >> > >> Regarding the definition of "feature freeze": I think it is good to > >> write down more of the implicit processes that we had in the past. The > >> bylaws, coding guidelines, and a better FLIP process are very good steps > >> towards the right direction. However, not everything can be written down > >> and formulized. We should also remind ourselves of basic software > >> engineering principles. Merging a feature shortly before the actual > >> release is always dangerous. A feature needs time to settle down and be > >> tested for side-effects etc. Merging a feature with a lot of spaghetti > >> code, reflection magic, and a single IT case is not a complete feature > >> that is worth merging. > >> > >> I hope we can improve here for the next release. Thanks for the open > >> discussion. > >> > >> Regards, > >> Timo > >> > >> > >> Am 08.08.19 um 11:11 schrieb Kurt Young: > >>> Hi Stephan, > >>> > >>> Thanks for bringing this up. I think it's important and a good time to > >>> discuss what > >>> does *feature freeze* really means. At least to me, seems I have some > >>> misunderstandings with this comparing to other community members. But > as > >>> you > >>> pointed out in the jira and also in this mail, I think your > understanding > >>> makes sense > >>> to me. > >>> > >>> Maybe we can have a conclusion in the thread and put this into the > >> project > >>> bylaws > >>> which are under discussion? > >>> > >>> Regarding to FLINK-13225, I would like to hear other's opinion since I > >>> merged it. But > >>> I would like to revert it if someone voted for reverting it. > >>> > >>> Sorry for the inconvenience I caused. > >>> > >>> Best, > >>> Kurt > >>> > >>> > >>> On Thu, Aug 8, 2019 at 4:46 PM Stephan Ewen <se...@apache.org> wrote: > >>> > >>>> Hi all! > >>>> > >>>> I would like to bring this topic up, because we saw quite a few > "secret" > >>>> post-feature-freeze feature merges. > >>>> The latest example was > >> https://issues.apache.org/jira/browse/FLINK-13225 > >>>> I would like to make sure that we are all on the same page on what a > >>>> feature freeze means and how to handle possible additions after the > >> feature > >>>> freeze. > >>>> My understanding was the following, and I assume that this was also > the > >>>> understanding of the community when we started establishing the > release > >>>> practice: > >>>> > >>>> - Feature freeze is the date until new features can be merged. > >>>> - After the feature freeze, we only merge bug fixes, release > relevant > >>>> tests (end to end tests), and documentation. > >>>> - Features should already be stable and have tests. It is not > okay to > >>>> "get a foot in the door" before feature freeze by merging something > >> that is > >>>> not ready (as a placeholder) and then fixing it post feature freeze. > >>>> - Extending functionality to new components is not a bug fix, it > is a > >>>> feature. > >>>> - If someone wants to add a minor feature after the feature > freeze, > >> and > >>>> there is a good reason for that, it should be explicitly discussed. If > >>>> there is no objection, it can be merged. > >>>> > >>>> Please let me know if you have a different understanding of what > feature > >>>> freeze means. > >>>> > >>>> Regarding the issue of FLINK-13225 > >>>> <https://issues.apache.org/jira/browse/FLINK-13225>? > >>>> - Should we keep it? > >>>> - Should we revert it in the release-1.9 branch and only keep it > for > >>>> master? > >>>> > >>>> Best, > >>>> Stephan > >>>> > >> > >
