doc: include security release proposal tutorial#43695
doc: include security release proposal tutorial#43695RafaelGSS wants to merge 1 commit intonodejs:mainfrom
Conversation
|
Review requested:
|
|
I think a reference in the section that says |
|
|
||
| *** | ||
|
|
||
| ## 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 |
5 participants
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.