Hey Dawid, Replying to your penultimate message: > We have never done something like this before I thought releasing usability features can be such an experiment. My reasoning is the following. As each release requires coordination of all the participating teams, it will not scale beyond some point. And Flink is growing rapidly. So we need to cut the scope of each release: - either by sub-project (i.e. separate release for each component; I think no one wants it?) - or by time/feature set (i.e. more frequent lightweight releases)
> However I am bit skeptical about the timing to do it now. I guess you are right. We should probably start release planning before the previous one is completed. So maybe 1.14 :) I think if anyone else is interested we can continue discussion in a separate thread. Thanks again for driving this effort! Regards, Roman On Mon, Jan 18, 2021 at 3:59 PM Dawid Wysakowicz <dwysakow...@apache.org> wrote: > Hi all, > > Thank you all for a warm reception as release managers. We are also glad > that the majority agrees we should aim for the end of March as the feature > freeze date. > > 1. Till created a page in our wiki to gather potential features that > we want to include in the release. Thank you Till! We'd kindly ask all > committers to fill in the page with features that they intend to work on. > We'd prefer if only new features end up there and not all bugs/tasks > separately so that the page is not over bloated. Of course, unless fixing a > bug is a really big or important one equivalent to implementing a > completely new feature. In our opinion a good rule of thumb would be that > each entry in the page could (but does not have to) be later on included in > a release blog post. > > The page can be accessed at: > https://cwiki.apache.org/confluence/display/FLINK/1.13+Release > > It would really help us if we knew what are the most critical features in > the release, so that we could keep a closer eye on those as potential > reasons for a delay or make a decision to cut the scope sooner. We were > thinking if it would be possible to mark certain features as "release > blockers". There should be no more than a single, unfinished one per > committer at a time. What do you think of that idea? > > > 1. Similarly to the previous release we would like to emphasize the > importance of keeping the build and tests stable. We think that worked > pretty well in the last release. Starting this week we will monitor any > build and/or test instabilities. Please expect nagging for a fix ;) > > You can check the current blockers in a dedicated kanban board here: > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=445 > > > 1. One of the biggest complaints for the past release(s) was lack of > proper documentation. Some features don't have a proper documentation even > though they were implemented a couple of releases ago. We'd like to remind > everyone that a decent documentation should always come hand in hand with > the code. We have even a checkmark for it in our PR template. ;) Lets try > to improve the situation a bit here! We should no longer allow ourselves to > postpone writing documentation to after the feature freeze. > > Your release managers, > Guowei & Dawid >
