doc: include security release proposal tutorial #43695
Conversation
|
Review requested:
|
|
I think a reference in the section that says |
| @@ -190,6 +190,131 @@ out a better way, forward the email you receive to | |||
| [Security release stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards). | |||
| If necessary add the next rotation of the steward rotation. | |||
|
|
|||
| *** | |||
|
|
|||
| ## Creating proposal | |||
There was a problem hiding this comment.
I'm still thinking this content should be in releases.md, with a reference in this file to follow the security release steps. I think maintaining the actual mechanics of release creation in two separate files will be make it more likely for them to become out-of-sync.
We also already have some of the security-specific information in releases.md (such as in https://github.com/nodejs/node/blob/main/doc/contributing/releases.md#5-create-release-commit), so at the moment this would duplicate it.
The actual steps look good though and useful to add though - thanks for writing them down!
There was a problem hiding this comment.
@BethGriggs I was kind of thinking the same thing but was happy to defer to what the release team thinks is best. I think having this closer to the other doc for creating releases makes sense to me, and then having a link in this doc to point to that section.
There was a problem hiding this comment.
Actually, this document points to the releases.md as a reference too. I've felt a very bad experience when the document tells you to go to another document and then back to the original one. For instance, this document contains:
2. Create a new branch for the release
Then as usual, create the proposal branch:
$ git checkout -b vXX.X.X-proposalWhich could be easily changed to
2. Create a new branch for the release
However, IMHO it makes the experience very bad and subjective to mistakes, for instance, I'll follow the releases.md in a security release, which might eventually leak sensitive information.
The major problem I see in having two documents is to keep them synced. But, I don't see the releases.md changing too much making the sync hard.
RafaelGSS
force-pushed
the
doc/include-security-release-steps
branch
from
755a035
to
d979d54
Compare
There was a problem hiding this comment.
I feel pretty strongly that this should be in releases.md and not in security-release-process.md. We already have steps in releases.md which cover security specifics, and I think we just need to highlight the ones that are missing (which you've covered in this PR).
Another reason I think this shouldn't be in security-release-process.md is because at the moment that document contains just the instructions for the security steward - the security steward doesn't need to care about the mechanics of the release process.
|
ping @nodejs/releasers |
Let me give a shot moving the content to the |
|
Closed in favor of #43835 |
While creating the next proposal. I missed a document containing a tutorial and as mentioned in the nodejs/Release#758 meeting, looks reasonable to have a section covering that.