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

Nominating new Release team members #4319

Closed
Fishrock123 opened this issue Dec 17, 2015 · 27 comments
Closed

Nominating new Release team members #4319

Fishrock123 opened this issue Dec 17, 2015 · 27 comments
Labels
meta Issues and PRs related to the general management of the project.

Comments

@Fishrock123
Copy link
Contributor

You do not have to be a TSC / CTC member to do releases.

Nominating two so far (also since they've volunteered their time)

cc @nodejs/ctc

@Fishrock123 Fishrock123 added the meta Issues and PRs related to the general management of the project. label Dec 17, 2015
@jasnell
Copy link
Member

jasnell commented Dec 17, 2015

+1 to both!

@rvagg
Copy link
Member

rvagg commented Dec 17, 2015

yar, +1 on both, particularly since @thealphanerd has been doing a lot of the heavy lifting with staging branches recently

@cjihrig
Copy link
Contributor

cjihrig commented Dec 17, 2015

+1 to both. I think we should cap it at those two for the time being though.

@bnoordhuis
Copy link
Member

One more +1.

@Fishrock123
Copy link
Contributor Author

I suppose the thing to do it to bring it up on the next TSC meeting then.

@jasnell
Copy link
Member

jasnell commented Dec 17, 2015

@Fishrock123 ... I'm not sure that's necessary. Seems like everyone is in agreement :-)

@rvagg
Copy link
Member

rvagg commented Dec 17, 2015

I wouldn't mind a CTC quorum on this, releases are a big deal and we should treat it as such cause you get access to put binaries on the server for redistribution so the CTC is effectively delegating its trust to these individuals. Enough +1's in here would probably be sufficient but I'd prefer a meeting so we have a clearer chain of evidence.

@jasnell
Copy link
Member

jasnell commented Dec 17, 2015

OK. Works for me

@Fishrock123
Copy link
Contributor Author

@thealphanerd / @evanlucas note: there's no solid process for this, but generally, we'll try to get you to do a patch or minor release while we are around to help. The actual release process is something you can only really learn to do by actually doing it. :)

@evanlucas
Copy link
Contributor

Works for me!

@MylesBorins
Copy link
Contributor

ditto. Perhaps I can shadow @jasnell on next weeks LTS release

@Fishrock123
Copy link
Contributor Author

@evanlucas & @thealphanerd could you make sure to have GPG keys setup as per https://github.com/nodejs/node/blob/master/doc/releases.md#3-a-publicly-listed-gpg-key?

Also having them on keybase.io is nice (let me know if you need an invite).

@MylesBorins
Copy link
Contributor

gpg --keyserver pool.sks-keyservers.net --recv-keys 38CE40DEEE898E15

@evanlucas
Copy link
Contributor

mine is gpg --keyserver pool.sks-keyservers.net --recv-keys B63B535A4C206CA9

@Fishrock123
Copy link
Contributor Author

From the CTC meeting, no objections.

@thealphanerd / @evanlucas Who wants to go first? Next week's stable release is as good as any to be your first. :)

@Fishrock123
Copy link
Contributor Author

doc/releases.md shows most of the process, and it would be good to familiarize yourself with it beforehand, although you'll probably follow along with it as you do your first release.

@MylesBorins
Copy link
Contributor

I'd be up for trying this.

@cjihrig
Copy link
Contributor

cjihrig commented Jan 8, 2016

@thealphanerd as you go through the process, could you take note of anything important that's missing from doc/releases.md?

@MylesBorins
Copy link
Contributor

absolutely

@Fishrock123
Copy link
Contributor Author

@evanlucas / @thealphanerd Could you make PR's adding your GPG keys to https://github.com/nodejs/node#release-team? We'll get the build team to add them then.

@rvagg
Copy link
Member

rvagg commented Jan 12, 2016

@evanlucas which key would you like us to use to give you promote access on the web server? https://github.com/evanlucas.keys — you'll need this done before you can run the full release process.

@evanlucas
Copy link
Contributor

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCvMVfdEy2ME3ZK+q+ib62rWWHNaUUmWDwaV/iMCfA3Vyisp2IXbQcbEt4hFduQX0nbbDnT6IKVRAzU7ya3H6m0ctiu7NkjejxseBQURrQYgMTS6F9Li9OE5vkyRfGr6Rx+4HQ8Ll6OtamE5dcEHy629rgsnFZQxOo/wYLPsEaUZuRrd9jEMiyDQghlzU+PtYKTO2B+U7qtCUU4tjpSfFBWV9V1XUmKEwAZfxeKWkWVcLpmFrE+6a+YKFz2uJNkFFRXdyVBMyZU9vLeFffNZSRX0lGllE57xF6A0f5yN7BIE48+qbJqfW/cADmH41ewuQEjXSjv3Ep6g17p5sjk0pu5

will work. Thanks!

@rvagg
Copy link
Member

rvagg commented Jan 12, 2016

Done, you should be good to go for a release now, maybe grab the next one, could even start the proposal later this week or early next week to line it up for next week or the week after.

I've been aiming for Tuesday releases where possible, I think @Fishrock123 has too. It's a bit of a sweet spot for releases but I don't think we need to be strict about it. I'd also prefer closer to a 2 weekly release average but I know @Fishrock123 has been pushing closer to 1.

@evanlucas
Copy link
Contributor

Will do. Thanks!

@Fishrock123
Copy link
Contributor Author

I'd also prefer closer to a 2 weekly release average but I know @Fishrock123 has been pushing closer to 1.

You mean bi-weeky or twice per week?

@rvagg
Copy link
Member

rvagg commented Jan 13, 2016

hah, because "bi-weekly" makes it more clear?

screen shot 2016-01-13 at 12 38 49 pm

2-weekly meaning every 2 weeks. A release frequency of every 1.5 weeks is probably a sweet spot for me.

@cjihrig
Copy link
Contributor

cjihrig commented Jan 13, 2016

How about fortnightly :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests

7 participants