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: de-duplicate security release processes #30996

Closed
wants to merge 1 commit into from

Conversation

@sam-github
Copy link
Member

sam-github commented Dec 16, 2019

The security release process is spread across multiple files. Merge
these two files to remove duplication and inconsistency. Also, make the
format more useful for inserting into the description of the Next
Security Release issue description.

This seems an obvious candidate for a github issue template, but if it
was, the content would not be reviewable by anyone outside of those on
the security teams, and the process should be public for purposes of
transparency and review.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
doing the release.

* [ ] Send an email to the docker official image
[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS)

This comment has been minimized.

Copy link
@sam-github

sam-github Dec 16, 2019

Author Member

@tianon @yosifkit -- could you please subscribe to https://groups.google.com/forum/#!forum/nodejs-sec ? Having to send the announcement emails to two distribution lists seems unnecessary. Note that the list is SPAM free. The only posts to it are the pre and post release announcements, and the process currently requires docker-specific notifications both pre and post release.

This comment has been minimized.

Copy link
@tianon

tianon Dec 16, 2019

Absolutely, I'm subscribed and I believe @yosifkit is as well.

This comment has been minimized.

Copy link
@sam-github

sam-github Dec 16, 2019

Author Member

So my extra email today was just spam :-(. Sorry! But it won't happen again if we get this landed.

This comment has been minimized.

Copy link
@tianon

tianon Dec 16, 2019

It's not a problem, I'd much rather get over-notified than under. 👍

[maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS)
with an FYI that security releases will be going out on the agreed date.

* [ ] Open an issue in the [docker-node](https://github.com/nodejs/docker-node)

This comment has been minimized.

Copy link
@sam-github

sam-github Dec 16, 2019

Author Member

@nodejs/docker could some members please subscribe to https://groups.google.com/forum/#!forum/nodejs-sec ? It is extremely low-traffic, it consists of one email a week before sec releases to warn you that they are coming, and of the date, and another email after the release so you can know to be ready to continue the docker release process.

This comment has been minimized.

Copy link
@LaurentGoderre
might be appropriate.

* [ ] Email foundation contact to tweet out nodejs-sec announcement from
foundation twitter account. FIXME - who is this contact?

This comment has been minimized.

Copy link
@sam-github

sam-github Dec 16, 2019

Author Member

@nodejs/tsc who is this contact? Is this even correct anymore? I think the twitter account may be in process of becoming a direct TSC responsibility again?

@Trott
Trott approved these changes Dec 17, 2019
@sam-github sam-github force-pushed the sam-github:integrate-sec-processes branch from 33447d2 to 34c433a Dec 30, 2019
The security release process is spread across multiple files. Merge
these two files to remove duplication and inconsistency. Also, make the
format more useful for inserting into the description of the Next
Security Release issue description.

This seems an obvious candidate for a github issue template, but if it
was, the content would not be reviewable by anyone outside of those on
the security teams, and the process should be public for purposes of
transparency and review.
@sam-github sam-github force-pushed the sam-github:integrate-sec-processes branch from 34c433a to 316e152 Dec 30, 2019
sam-github added a commit that referenced this pull request Dec 31, 2019
The security release process is spread across multiple files. Merge
these two files to remove duplication and inconsistency. Also, make the
format more useful for inserting into the description of the Next
Security Release issue description.

This seems an obvious candidate for a github issue template, but if it
was, the content would not be reviewable by anyone outside of those on
the security teams, and the process should be public for purposes of
transparency and review.

PR-URL: #30996
Reviewed-By: Rich Trott <rtrott@gmail.com>
@sam-github

This comment has been minimized.

Copy link
Member Author

sam-github commented Dec 31, 2019

Landed in c052113

@sam-github sam-github closed this Dec 31, 2019
BridgeAR added a commit that referenced this pull request Jan 3, 2020
The security release process is spread across multiple files. Merge
these two files to remove duplication and inconsistency. Also, make the
format more useful for inserting into the description of the Next
Security Release issue description.

This seems an obvious candidate for a github issue template, but if it
was, the content would not be reviewable by anyone outside of those on
the security teams, and the process should be public for purposes of
transparency and review.

PR-URL: #30996
Reviewed-By: Rich Trott <rtrott@gmail.com>
@BridgeAR BridgeAR mentioned this pull request Jan 7, 2020
targos added a commit that referenced this pull request Jan 14, 2020
The security release process is spread across multiple files. Merge
these two files to remove duplication and inconsistency. Also, make the
format more useful for inserting into the description of the Next
Security Release issue description.

This seems an obvious candidate for a github issue template, but if it
was, the content would not be reviewable by anyone outside of those on
the security teams, and the process should be public for purposes of
transparency and review.

PR-URL: #30996
Reviewed-By: Rich Trott <rtrott@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.