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 "Liked, learned, Lacked, and Longed for".
Best regards, Jing On Wed, Nov 2, 2022 at 11:21 AM Martijn Visser <martijnvis...@apache.org> wrote: > 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 be the questions that you > would normally ask during a retrospective yet but now via a questionnaire. > It probably makes sense to have a proposal of the questions that can be > asked, discuss them and then sent them out. > > WDYT? > > Thanks, > > Martijn > > On Wed, Nov 2, 2022 at 9:42 AM Qingsheng Ren <re...@apache.org> wrote: > > > 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 open a discussion thread in ML at > > the end of the release to collect feedback about the last release cycle > and > > add them to the release wiki page, which would be quite handy for further > > RMs. > > > > Best, > > Qingsheng > > Ververica (Alibaba) > > > > On Mon, Oct 31, 2022 at 11:02 PM Matthias Pohl > > <matthias.p...@aiven.io.invalid> wrote: > > > > > 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 find this > > > useful? Or was this already done but not helpful? > > > > > > I see three options here: > > > 1. Having an actual meeting where issues can be discussed and/or > > > experiences can be shared between the release managers of the previous > > > release and the release managers of the next minor release. Of course, > > this > > > could be open to other contributors as well. A summary could be > provided > > in > > > the Flink wiki (the Flink release's wiki article). > > > 2. The release manager(s) provide a summary on the Flink release's wiki > > > article as part of the release process. > > > 3. Leave the process as is without any additional retrospective but > focus > > > on improving the documentation if issues arose during the release. > > > > > > That might help people who consider contributing to the community > through > > > supporting the release efforts. Additionally, it might help in > > > understanding what went wrong in past releases retroactively (e.g. the > > > longer release cycle for 1.15). > > > > > > I'm curious about opinion's on that topic. > > > > > > Best, > > > Matthias > > > > > >
