Skip to content
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

Merged
merged 3 commits into from
Feb 14, 2019

Conversation

rvagg
Copy link
Member

@rvagg rvagg commented Nov 21, 2018

Coming out of #390 I've done some updating of the process for adding new releasers.

Clean-up, plus I've Added:

  • Guidance on SSH key complexity and how to make one
  • Notes about SSH & GPG key compromise
  • Rules for starting new LTS releases (start with a Current)

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

Copy link
Contributor

@MylesBorins MylesBorins left a 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

GOVERNANCE.md Outdated Show resolved Hide resolved
GOVERNANCE.md Outdated Show resolved Hide resolved
GOVERNANCE.md Outdated Show resolved Hide resolved
promote the new GPG key to the user ecosystem prior to it being required to
verify an LTS release

### SSH key guidance
Copy link
Contributor

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

GOVERNANCE.md Outdated Show resolved Hide resolved
Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@MylesBorins
Copy link
Contributor

ping @rvagg would you mind if I updated this based on the comments?

@rvagg
Copy link
Member Author

rvagg commented Dec 18, 2018

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.

rvagg and others added 2 commits January 23, 2019 10:51
* guidance on SSH key complexity
* notes about SSH & GPG key compromise
* rules for starting new LTS releases (start with a Current)
@MylesBorins MylesBorins force-pushed the rvagg/update-add-releaser-process branch from 1ea33da to dc998e0 Compare January 23, 2019 15:54
@MylesBorins
Copy link
Contributor

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

@MylesBorins
Copy link
Contributor

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

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still LGTM

GOVERNANCE.md Outdated Show resolved Hide resolved
@MylesBorins MylesBorins merged commit f44a80f into master Feb 14, 2019
@Trott Trott deleted the rvagg/update-add-releaser-process branch September 6, 2022 03:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants