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

alter blog post pushing guidelines and commits to nodejs.org master #8629

Closed
ghost opened this issue Sep 17, 2016 · 14 comments
Closed

alter blog post pushing guidelines and commits to nodejs.org master #8629

ghost opened this issue Sep 17, 2016 · 14 comments
Labels
meta Issues and PRs related to the general management of the project.

Comments

@ghost
Copy link

ghost commented Sep 17, 2016

so one thing that's been bugging me is the process for blog post publishing in the nodejs.org repo. releases.md states that you should immediately merge the blog post PR, however this goes against every other process we have in the website WG. same goes for pushing to master (looking at you @mikeal). could we at least try to change the document so that there needs to be a signoff by a TSC/CTC member or something?

@ghost ghost changed the title alter blog post pushing guidelines and commits to node.org master alter blog post pushing guidelines and commits to nodejs.org master Sep 17, 2016
@cjihrig
Copy link
Contributor

cjihrig commented Sep 17, 2016

FWIW, I think all of the people who have been doing releases are CTC members.

@MylesBorins
Copy link
Contributor

@fene the issue that we will primarily deal with is that when doing a release everything is very time sensitive. In order to generate the release post we need the sha's and size information for all the assets in the tarball. This information is not available to the website tool until the release has been promoted. Once the release is promoted we want to get the post up ASAP.

Adding an extra sign off step will only block to release process IMHO. Seeing as how the the post is 100% generated / automated, it doesn't really make sense to me that it should need sign off.

Is there a halfway point that we can land on this? Would making sure all commits follow the proper guidelines with titles / descriptions?

@ghost
Copy link
Author

ghost commented Sep 17, 2016

@thealphanerd i'd at least appreciate that, yeah. maybe a short notice on the PR that it doesn't need a sign-off or something?

@MylesBorins
Copy link
Contributor

could we include a shorthand in the title that signals that?

For example

release-post: v4.5.1

This commit includes a blog post with release information for v4.5.1

I think the issue starts to become one of redundancy... when the body is not saying much more than the title at all.

@ghost
Copy link
Author

ghost commented Sep 17, 2016

oh yeah, that would probably work

@MylesBorins
Copy link
Contributor

Here is one from @Fishrock123 I like.

Blog: v6.6.0 release post

Refs: https://github.com/nodejs/node/pull/8466

Includes a reference to the original PR for the release.

I did just audit the various commits within the website and noticed that there does not appear to be any consistency regarding having a body to a commit. A non trivial number of commits from various wg members appear to be with only a title. As such should we be expecting a higher bar for Blog pr's?

@mscdex mscdex added the meta Issues and PRs related to the general management of the project. label Sep 17, 2016
@ghost
Copy link
Author

ghost commented Sep 17, 2016

there is no specific rule for this in the CONTRIBUTING.md for the website repo, no. however, since the blog PRs are instantly merged (unlike all others), which makes them special, i think that they should include a special description that other commits may not have

@MylesBorins
Copy link
Contributor

@fene ok. Can you please send a PR to Release.md that outlines the new process? We can make sure to get sign-off from all the releasers before landing

@ghost
Copy link
Author

ghost commented Sep 17, 2016

@thealphanerd can i edit the document to link to guidelines that i'll add in the website repo?

@MylesBorins
Copy link
Contributor

I would include the full instructions in that document with exactly what
you would like done. pointing to another document can be somewhat frail.

On Sat, Sep 17, 2016, 4:39 PM fen notifications@github.com wrote:

@thealphanerd https://github.com/TheAlphaNerd can i edit the document
to link to guidelines that i'll add in the website repo?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8629 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAecV5xZ-PnC_fKowQIAOCm2cbHyZKSdks5qq_urgaJpZM4J_l7r
.

@ghost
Copy link
Author

ghost commented Sep 17, 2016

alright, fair enough

@Fishrock123
Copy link
Contributor

FWIW, I think all of the people who have been doing releases are CTC members.

This isn't necessarily true, nor should it be.

I'd be ok with some commit message guidelines, but I think releasers should still always be able to publish immediately.

The same rights also count for the core repo where releasers are able to push releases without other explicit signoff in many cases. This includes updating the changelog in master without a PR.

Requiring a PR for that would just not work with how the release post tooling works here.

@cjihrig
Copy link
Contributor

cjihrig commented Sep 17, 2016

This isn't necessarily true, nor should it be.

I agree, I was just stating the current reality in response to the comment that TSC/CTC signoff should be required.

@MylesBorins
Copy link
Contributor

one thing that I think is important to remember is the purpose of process

process exists to help us succeed as a group. it is not set in stone, note
does it exist for its own sake.

generally productivity will trump process. pushing release notes directly
to master is a great example I had not considered including.

I think the issue here is that of respect. I have been opening prs for all
release posts primarily out of respect to the wg. obviously this had not
been properly conveyed.

i really like the idea of including the pr URL in the body of the commit as
extra meta data, and that being a sign of respect for the process.

to the website wg, I apologize if the process has created an environment
that you feel disrespected. hopefully this new process will work better.
with that being said, I do urge you to consider why certain process exists,
and not be afraid of questioning things before it becomes dogma.

all that aside, respect comes first. thanks for being patient

On Sat, Sep 17, 2016, 7:24 PM Colin Ihrig notifications@github.com wrote:

This isn't necessarily true, nor should it be.

I agree, I was just stating the current reality in response to the comment
that TSC/CTC signoff should be required.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8629 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAecV4d-dczoP201WkQsbFcP6nIb354Dks5qrCJpgaJpZM4J_l7r
.

jasnell pushed a commit that referenced this issue Sep 29, 2016
this commit enhances the guidelines to creating a release blog post, specifically by adding
a commit format that must be adhered to when creating a pull request on the website repository

Fixes: #8629

PR-URL: #8631
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: James M Snell <jasnell@keybase.io>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
MylesBorins pushed a commit that referenced this issue Sep 30, 2016
this commit enhances the guidelines to creating a release blog post, specifically by adding
a commit format that must be adhered to when creating a pull request on the website repository

Fixes: #8629

PR-URL: #8631
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: James M Snell <jasnell@keybase.io>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
MylesBorins pushed a commit that referenced this issue Oct 10, 2016
this commit enhances the guidelines to creating a release blog post, specifically by adding
a commit format that must be adhered to when creating a pull request on the website repository

Fixes: #8629

PR-URL: #8631
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: James M Snell <jasnell@keybase.io>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Fishrock123 pushed a commit that referenced this issue Oct 11, 2016
this commit enhances the guidelines to creating a release blog post, specifically by adding
a commit format that must be adhered to when creating a pull request on the website repository

Fixes: #8629

PR-URL: #8631
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: James M Snell <jasnell@keybase.io>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
rvagg pushed a commit that referenced this issue Oct 18, 2016
this commit enhances the guidelines to creating a release blog post, specifically by adding
a commit format that must be adhered to when creating a pull request on the website repository

Fixes: #8629

PR-URL: #8631
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: James M Snell <jasnell@keybase.io>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
MylesBorins pushed a commit that referenced this issue Oct 26, 2016
this commit enhances the guidelines to creating a release blog post, specifically by adding
a commit format that must be adhered to when creating a pull request on the website repository

Fixes: #8629

PR-URL: #8631
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: James M Snell <jasnell@keybase.io>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
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

4 participants