Fix release template issues/gaps (v0.11 edition)

[BigLep]

During the 0.11 releases, we identified various gaps in the release process template. This issue captures the items that need to be addressed in the template, ideally before before we do the next release. This has some carry-over from previous releases (#8248 )

• Address this gap: Reach out to PL comms team after the initial release notes are drafted and then more closely the week of the release
• Document in detail how to run test, so that anyone can do it for a release
  • (@lidel will do it) IPFS Companion
• Remove the copy/pasted content in https://docs.ipfs.io/how-to/configure-node/
• Have a single Discuss post for RC's so that interested testers can just watch the post for when we post new RCs. Template needs to be updated to reference that post in the "Invite the wider community through (link to the release issue)" section
• @lidel: Add Brave to the group of early testers so they get notified of a new version.
• Add a step for manually running the FUSE and Docker tests since they don't run in CI
• Clean up the "Update HTTP-API Documentation on the Website using ipfs/http-api-docs" and "Update CLI Documentation on the Website" steps to account for automation.
• Review the package managers in https://github.com/ipfs/go-ipfs#native-linux-package-managers
• Offload the communication side of releases (except for internal #ipfs)
• Change the "where to go for questions" section to match what's in the v0.11.0 release notes (e.g. no more Freenode references)
• Remove/rework the "Would you like to contribute to the IPFS project and don't know how? Well, there are a few places you can get started:" section since some of the linked calendars and such are no longer valid.
• Add instructions to manually run GH Actions to generate release binaries and attach to release before making announcements (for both final and RC releases), just click the button here https://github.com/ipfs/go-ipfs/actions/workflows/sync-release-assets.yml
• Update "Invite the wider community through (link to the release issue):" to make clear we do discuss post for each release including RCs and that handles Matrix automatically.
• Add step for communicating with operator group about new RC
• Update details regarding engaging marketing
• Add a step for updating our infra to use our final release
• Add a step reviewing infra config. Should be able to answer what to do based on release notes.
• Add a step for reviewing/updating dependency versions (could be running a go command, looking at dependabot PRs)

[BigLep]

@galargh : before we started doing a PR per release for fixing up the release template, we had accumulated some improvements here. I'm not sure how many of these are still relevant. When you free up, can you please own going through this and seeing what is still relevant? Thank yo.

[galargh]

I'll review it ahead of v0.18.0-RC1

[galargh]

Address this gap: Reach out to PL comms team after the initial release notes are drafted and then more closely the week of the release

This is not part of the release process. Is it obsolete now?

Remove the copy/pasted content in https://docs.ipfs.io/how-to/configure-node/

Do you know what this is referring to?

Have a single Discuss post for RC's so that interested testers can just watch the post for when we post new RCs. Template needs to be updated to reference that post in the "Invite the wider community through (link to the release issue)" section

We could do that. However, only the top level post is reposted to matrix, Slack, etc. So I wanted to confirm first if that's desired.

Add Brave to the group of early testers so they get notified of a new version.

Working on this one in #9487

Add a step for manually running the FUSE and Docker tests since they don't run in CI

I think we do run docker tests now. What's the reason for not TEST_NO_FUSE=1 flag? https://github.com/ipfs/kubo/blob/master/.circleci/main.yml#L152

Review the package managers in https://github.com/ipfs/go-ipfs#native-linux-package-managers

✅ In review: #9488

Offload the communication side of releases (except for internal #ipfs)

I'm assuming bridges between different channels take care of this.

Add step for communicating with operator group about new RC

I'm assuming this means bifrost team.

Add a step reviewing infra config. Should be able to answer what to do based on release notes.

Do we want to review all of this - https://github.com/protocol/bifrost-infra/tree/master/ansible/inventories/bifrost/group_vars - during the release?

Add a step for reviewing/updating dependency versions (could be running a go command, looking at dependabot PRs)

Do we want to do that during the release?

[BigLep]

@galargh : ACK that you have some questions here. It's on my list to circle back this week.

[BigLep]

Thanks for seeing this through @galargh !

Address this gap: Reach out to PL comms team after the initial release notes are drafted and then more closely the week of the release

This is not part of the release process. Is it obsolete now?

Yeah, obsolete. Let's strike it out.

Remove the copy/pasted content in https://docs.ipfs.io/how-to/configure-node/

Do you know what this is referring to?

No. Let's strike it out.

Have a single Discuss post for RC's so that interested testers can just watch the post for when we post new RCs. Template needs to be updated to reference that post in the "Invite the wider community through (link to the release issue)" section

We could do that. However, only the top level post is reposted to matrix, Slack, etc. So I wanted to confirm first if that's desired.

Good callout. Is the way to satisfy all usecases to do a post per release and to have a long running post that someone can be subscribed to? The long running post will just link to the individual release posts?

Add a step for manually running the FUSE and Docker tests since they don't run in CI

I think we do run docker tests now. What's the reason for not TEST_NO_FUSE=1 flag? https://github.com/ipfs/kubo/blob/master/.circleci/main.yml#L152

We do need to run Docker tests - great that that is happening automatically. now!
Let's not worry about FUSE. This isn't an area we're gong to invest in. (An issue concerning deprecating it needs to be created, but that's a separate item).

Offload the communication side of releases (except for internal #ipfs)

I'm assuming bridges between different channels take care of this.

This was more about the marketing announcement, etc. I think we have this weel covered and can call this done.

Add step for communicating with operator group about new RC

I'm assuming this means bifrost team.

This is about posting in the FIL Slack private #ipfs-operators channel.

Add a step reviewing infra config. Should be able to answer what to do based on release notes.

Do we want to review all of this - https://github.com/protocol/bifrost-infra/tree/master/ansible/inventories/bifrost/group_vars - during the release?

I think we want to make sure that the Kubo configuration being used in production makes sense to us and is giving us the kind of feedback we'd want about Kubo. Ideally this gets to a state where we check to see "was there any new config options or changes? If so, should we leverage them in Bifrost"? I agree this will be harder to mechanize. I would check to see if @guseggert has thoughts here.

Add a step for reviewing/updating dependency versions (could be running a go command, looking at dependabot PRs)

Do we want to do that during the release?

I assume the concern here is the variability it will bring during release time. The main concern here is to make sure we have a mechanism where we're updating things. Doing so after the release makes sense. My only expectation is that it happens periodically and that it doesn't rely on best intentions.

[galargh]

Add a step reviewing infra config. Should be able to answer what to do based on release notes.

Do we want to review all of this - https://github.com/protocol/bifrost-infra/tree/master/ansible/inventories/bifrost/group_vars - during the release?

I think we want to make sure that the Kubo configuration being used in production makes sense to us and is giving us the kind of feedback we'd want about Kubo. Ideally this gets to a state where we check to see "was there any new config options or changes? If so, should we leverage them in Bifrost"? I agree this will be harder to mechanize. I would check to see if @guseggert has thoughts here.

I think maybe What's left for release? > Required is a good place for that. That way we'd look at it during standup and if anyone has any concerns, they can raise them there and turn into PRs. I added it to the 0.19 as an example: #9502

[galargh]

I'm going to close this one now as we completed most of the items here. Things to consider in the future: modifying how we create Discuss posts during the release (if we do want to proceed with the changes in this area, let's create a new issue).