20.09 Release Retrospective

Meta Moderation
12

This one I’m not sure we should talk about, really I think we said it was okay that we didn’t do that. We have a staging-next for master because it rebuilds so much, on release staging the influx of changes is greatly smaller so a single staging branch has been sufficient like on master back then.

13

The problem is that merging PRs which target staging-20.09 brings it to a branch which will start an evaluation of it and affects current stabilization efforts. This is bad because if you merge a few PRs in different evaluation periods, we will use a lot more hydra resources than we should; and if the branch is trying to be stabilized, then it’s annoying to iterate on a branch which may get large rebuild commits.

For non-x86-linux, hydra resources are already spread very thin: Hydra - Queue summary

14

Tentative time will be Tuesday, Nov 10 at 1200 PST / 1500 EST / 2000 GMT

15

I created a google cal invite, at the time previously mentioned. Anyone is free to join. @worldofpeace may not be able to join, but expecting @garbas to be present.

Going to conduct the meeting using Pivotal labs retrospective techniques, best reference I could find is https://tanzu.vmware.com/content/blog/how-to-run-a-really-good-retrospective , however, it’s shy on the details.

I will come prepared with a pre-made list of items from this thread. However, people joining are welcome to add additional items. Then the meeting will go as follows:

  • Introductions
  • Brief description of the items, and why they are relevant
  • everyone has 5 votes, vote once per topic or as many times for a topic up to 5 total votes
  • Begin time-boxed discussion on the topics, starting with the most popular topic, and working down
    • 5 min initial discussion
    • 2 min extensions, depending on majority vote.
  • If an “action item” comes out of discussion, then I will record it.

I’m used to doing these in-person with a team. Not sure how this will translate to a video conference. If it’s just @garbas and I, it will probably pretty informal, but representative to the process described above.

16

It seems as if your link just opens my calendar without any clues about your scheduled event, if I try to open in an incognito tab, google asks me to log in first.

Sadly I can not really find “the time previously mentioned” (Except for a sidenote it beeing biased to American timezones).

Can you perhaps use a date tag?

[date=2020-11-10 time=00:00:00 timezone="Europe/Paris"] → [date=2020-11-10 time=01:00:00 timezone="Europe/Paris"]
17

meeting room: https://meet.google.com/dhs-nxbm-ygg
2020-11-10T20:00:00Z → 2020-11-10T21:30:00Z

g cal invite (same as above):

1 Like
18

Rescheduling as neither @worldofpeace and @garbas weren’t able to make it.

New date:
2020-11-13T21:00:00Z → 2020-11-13T22:30:00Z
Room: https://meet.google.com/yzv-ynuw-fjb

19

A negative:

  • I think ZHF could have been a lot shorter if email notifications from hydra were enabled, and judging by the amount of reactions on this comment, I am not the only one with this opinion (22 :+1:s at the time of writing. by comparison the OP has 30 :tada:s)
6 Likes
20

Having some kind of notification even outside of ZHF would be beneficial. The ideal time to fix something is when it’s first broken on master.

I would also like some type of notification of breakages.

3 Likes
21

That’s what I meant! If breakages are fixed continuously as soon as they happen, then we wouldn’t have as many at release time, and we wouldn’t need to backport them

6 Likes
22

I agree. Though it would be nice to have some filtering. Some of the packages that I maintain or update regularly fail on Hydra with illegal instruction because the CPUs in some of the Hydra machines are too old :frowning: .

1 Like
23

Unfortunately I wasn’t able to record last moment (obs was working tuesday, but was grumpy today).

20.09 Retro Action Items

  • Release process RFC, changing to YY.05 and YY.11 schedule @jonringer
  • Change branch-off convention @jonringer
    • 2 week prior to branch-off, ZHF on master?
  • Include documentation on release process to get hydra permissions
    • creation of jobset or reserve someone ahead-of-time to be available
  • Also support previously support release notes. cc @garbas
    • We only carry two currently: Unstable and latest release
    • Should be Unstable, release-beta, release during ZHF
    • Should be Unstable, new release, old release until old release is EOL
  • Potential bot to delcare changelog source, and other review materials
    • A lot of this information can be extracted from the expressions, would be nice to easy reviews.
    • For example, nixpkgs-update does this in the initial PR post, but it’s largely not done for other PRs
  • Additional documentation around conducing reviews of PRs @jonringer

Thanks to those who participated:
@aanderse
@ryantm
@Kiwi
@NobbZ
@redvers

2 Likes
24
1 Like
25

I’m saying that it should list ones which are still “current”, which would be 3 beginning with ZHF and until the previous release is EOL. For example, 20.03 is still support until a month after 20.09 has been release, but there’s no way to access the manual through the website

26

And the search on the other hand site at search.nixos.org still reaches back to 19.09.

27
28

I didn’t realize how much you wrote for the rfc (I had very little desire to do any writing lately).

Thanks!

29

I’m going to break this out into two different RFCs, much like avoiding large PRs, avoiding large RFCs will help them separate concerns and get merged or closed faster

1 Like
30

RFC for changing release months: [RFC 0080] Change NixOS releases to YY.05,YY.11 by jonringer · Pull Request #80 · NixOS/rfcs · GitHub

1 Like
31

2nd RFC regarding how ZHF is conducted [RFC 0085] NixOS Release Stabilization: ZHF on master, new timeline by jonringer · Pull Request #85 · NixOS/rfcs · GitHub

EDIT: ZHS → ZHF

3 Likes