Lilac release retrospective

Working Groups Build-Test-Release
1

@nedbat made a great suggestion during this week’s contributor’s meetup: to start an asynchronous retrospective on the Lilac release process. So, if you had anything to do with the release, we’re interested in hearing what about the process:

  • Went well and should continue (or done even more!)
  • Didn’t go so well and needs improvement
  • Sucked and needs to be dropped or totally revamped for Maple

I’m personally interested in comparing what actually happened to the original plan, but I’ll refrain from giving my own opinion until most of you have spoken.

I’m going to tag some of you so you see this in time before next week’s build-test-release meeting (@regis, @nedbat, @BbrSofiane, @pdpinch, @jhony_avella, @sambapete), but this doesn’t mean we’re only interested in their opinion. Anybody’s welcome to comment.

2

I won’t be present next week since I will be on vacation for the next 2 weeks, but I’ll try to attend if it rains. I might write something beforehand.

2 Likes
3

That’s the idea! You don’t need to be present in the meeting for your ideas to be taken into account. :slight_smile:

1 Like
4

(Off the top of my head, so I might edit over time…)

Things I liked:

  • Release notes!
  • Shipped on the desired day!
  • More ownership by the group as a whole
  • GitHub project board worked to organize us, esp with @BbrSofiane’s scrum-mastership
  • CI was giving us good information
  • We worked through some hard release management decisions

Things that could have gone better:

  • The process wiki page is too long to be able to use as a checklist. Maybe some way to create GitHub Project tickets for everything up-front?
    • Some tasks were still being discovered after the release
  • We didn’t have clear signals of testing happening, and what the outcomes were.
  • (Didn’t we have some breakage surprises? I’m forgetting the details…)
2 Likes
5

I think there were many important improvements over the Koa and Juniper releases. Notably:

  • much better organization and communication
  • ownership of major tasks (such as the release notes and the MFE deployment) by the working group members

What should definitely have gone better was the tagging of rc1, which should have happened earlier. As it stands, my gut feeling is that Lilac did not get a lot of testing.

1 Like
6

What I think went well:

  • Better organisation by the virtue of having roles
  • Information sharing for some complex issues (e.g. the amount of information in issue#30)
  • We developed a bit of a cadence (2-week milestone) that we should build upon

What I think didn’t go so well:

  • Testing of release candidates still felt quite exploratory

What I think we could improve:

  • Get more people involved
1 Like
7

Thanks for your input so far! I’ve started a Lilac.1 Release Retrospective wiki page on Confluence based on the input above, while also adding some thoughts of my own. We’ll go through the list during the meeting and adjust it as necessary to make it as useful as possible as a guide for the Maple release cycle.

8

Things I liked:

  • Dates and timing worked much better than in the past, both in terms of how long we had between the cut and the release, and also where the release fell on the calendar. I think the current pacing is ideal.
  • The effort was shared over a wider group
  • We created a lot of institutional knowledge

Things that could have gone better:

  • Functional testing was thin, and is very hard for highly-customized features (e-commerce, theming)
  • Still more work to do on improving, capturing processes (in particular, release notes)
  • docker devstack images were overlooked, and I still don’t know how they get created