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?
FWIW, I think all of the people who have been doing releases are CTC members.
@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?
@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?
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.
oh yeah, that would probably work
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?
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
@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
@TheAlphaNerd can i edit the document to link to guidelines that i'll add in the website repo?
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 [email protected] 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
https://github.com/nodejs/node/issues/8629#issuecomment-247776633, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAecV5xZ-PnC_fKowQIAOCm2cbHyZKSdks5qq_urgaJpZM4J_l7r
.
alright, fair enough
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.
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.
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 [email protected] 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
https://github.com/nodejs/node/issues/8629#issuecomment-247791501, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAecV4d-dczoP201WkQsbFcP6nIb354Dks5qrCJpgaJpZM4J_l7r
.
Most helpful comment
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 [email protected] wrote: