I updated the Flink release wiki article [1] as discussed in my previous
email. An explicit request for feedback on the release process will be part
of the release announcement from now onwards.
Additionally, I added a subsection in wrapping up the release where we
suggest creating a summary per re
Thanks for all the insights on how it was done in the past and the pro's
and con's of the different approaches. ...also being reminded on how we did
it for 1.14 and the positive feedback we got from it was helpful.
I like the idea of an async survey. I also think that utilizing the mailing
list fo
Hi,
We did something like this for the 1.14 release [1].
We did that in an async survey-style way approaching key contributors
directly. I also think the output was quite nice and we got positive
feedback for what we published.
I think Robert mentioned they did something similar in the past, with
Thanks for starting the discussion, Matthias!
When I was the 1.16 release manager, I checked the dev mailing list to see
what the release managers of the previous two versions did throughout the
release cycle. In release 1.16, after each release sync meeting, we would
send a summary email, which c
Hi all,
I figure it is a good idea and +1 for the async retro. More developers will
learn from what the release process looks like, which will give them
context to engage in future releases. It would be great if the conversation
could somehow follow the traditional retro pattern, e.g. tagged with
Hi Matthias,
I think it's a good idea to capture how this release cycle has progressed.
I'm not sure that a classical "retrospective" is the best solution, since
it would require multiple people in different timezones to attend a virtual
meeting.
So I would +1 an async retrospective, which could
Thanks for starting the discussion Matthias!
I think having a retro after a release cycle would be quite helpful to
standardizing the procedure of the release, and also could avoid new
release managers getting stuck on the same issue that happened before. I
prefer the second option that RMs could
Hi everyone,
I want to bring up the idea of having a retrospective on the release from
the release manager's perspective. The idea would be to collect feedback on
what went well and what could be improved for a specific minor release. So
far, I didn't find anything on that topic. Does the community
