-
Notifications
You must be signed in to change notification settings - Fork 576
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: update the releaser onboarding process and rules #393
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a few comments inline
promote the new GPG key to the user ecosystem prior to it being required to | ||
verify an LTS release | ||
|
||
### SSH key guidance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great. I'd love a follow up with similar guidelines for gpg
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
ping @rvagg would you mind if I updated this based on the comments? |
yeah, sorry @MylesBorins, busy month. I'll get back to this soon but if you want to take over this you're more than welcome to. |
* guidance on SSH key complexity * notes about SSH & GPG key compromise * rules for starting new LTS releases (start with a Current)
1ea33da
to
dc998e0
Compare
I've rebased and updated. I kept the initial commit as identical to the original commit (modulo upstream changes)... made updates in a new comimt PTAL |
Worth mentioning this maintains the rule around having to promote a current release before LTS. We have had friction with this right now, but I also think that may be related to how many people we onboarded at once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still LGTM
Coming out of #390 I've done some updating of the process for adding new releasers.
Clean-up, plus I've Added:
The one thing I'm not sure about, but is already in here, is why all new releasers get added to nodejs-private? Perhaps that should be a separate step so as to give us more flexibility in adding releasers outside of the TSC while not expanding nodejs-private access too much. Security releases are a major ordeal and more important than even LTS releases to get right. And in practice, very few of us even do them because of the massive workload and complexity involved—and past experimentation with multiple releasers coordinating hasn't gone well. Happy to leave this in here for now but it might be worth discussing.
/cc @nodejs/release, @nodejs/releasers & @nodejs/build