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: specify fast-tracking #22929

Closed
wants to merge 2 commits into from

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Sep 18, 2018

Update: please check the commit message as description.

It is currently not clear if a PR approval also approves the
fast-tracking request. This simplifies things by explicitly asking
the collaborators to remove the label if they disagree with it and
that any PR approval is also a fast-tracking approval from as soon
as the label is attached to the PR.

@nodejs/collaborators PTAL (sorry for pinging everyone but since this
is important for each one of us, it's important that everyone is on the same
page).

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

@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Sep 18, 2018
@tniessen
Copy link
Member

+1 for the the simplicity, but I'd prefer to have the possibility to approve a PR without approving or rejecting the fast-tracking request without having to explicitely state this. I liked the convention to add a comment along the lines of "Please add 👍 here to approve fast-tracking" (I think @vsemozhetbyt introduced that?).

@targos
Copy link
Member

targos commented Sep 18, 2018

I like the use of a comment with upvotes. What's wrong with it?

@BridgeAR
Copy link
Member Author

If we give a LG to a PR, should we not also agree on fast-tracking or not? If someone disagrees, removing the label right away is best :)

That way it's always clear what the intention is and it's more straight forward than having an extra comment that we have to upvote.

@tniessen
Copy link
Member

If we give a LG to a PR, should we not also agree on fast-tracking or not?

@BridgeAR I don't think we should make that implication.

  • IMO approvals on GitHub are not flexible enough anyway, e.g. it would be great if one could only approve code or docs or fast-tracking etc. If anything, it should be possible to approve smaller parts, and this change contradicts that.
  • It is an additional burden while reviewing: What if I am not sure whether the change should be fast-tracked but I still want to approve it?
  • It is easy to miss a label: Oh wait, I approved fast-tracking? (Passive vs active approval)
  • Setting a label doesn't notify people who previously approved, a comment does.
  • If one has already approved the change and later notices that the fast-track label was set afterwards, one needs to approve the change again by going to "files → review → approve" instead of just clicking 👍 on a comment.

@addaleax
Copy link
Member

No strong preferences here, but a couple of quick thoughts:

  • The 👍-a-comment solution has been effectively the standard way of doing this for a long time now, and has worked pretty well
  • As a rule of thumb, explicit > implicit, and implicitly reading an approval of one thing as an approval of something else is something we’d probably want to avoid
  • The solution suggested here (adding/removing labels as necessary) might play better with a commit queue

@BridgeAR BridgeAR force-pushed the specifiy-fast-tracking branch from 97535c9 to 3bb07f9 Compare September 18, 2018 12:21
@BridgeAR
Copy link
Member Author

I just reworded it to keep the comment type but to be specific about it.

approve both the pull request and the fast-tracking request, and the necessary
CI testing is done.
`fast-track` and add a comment that collaborators may upvote. Please mention the
collaborators that gave a approval before in that comment. If someone disagrees
Copy link
Contributor

Choose a reason for hiding this comment

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

a approval -> an approval.

@vsemozhetbyt vsemozhetbyt added the meta Issues and PRs related to the general management of the project. label Sep 18, 2018
Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Sep 18, 2018
@BridgeAR
Copy link
Member Author

@BridgeAR BridgeAR added the fast-track PRs that do not need to wait for 48 hours to land. label Sep 18, 2018
@BridgeAR
Copy link
Member Author

Please +1 if you agree with fast tracking.

@richardlau richardlau removed the fast-track PRs that do not need to wait for 48 hours to land. label Sep 18, 2018
Copy link
Member

@richardlau richardlau left a comment

Choose a reason for hiding this comment

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

Approving, but I don't think this PR should be fast tracked to allow other collaborators a chance to review (especially given that all collaborators were pinged).

Copy link
Contributor

@mmarchini mmarchini left a comment

Choose a reason for hiding this comment

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

LGTM, but I agree with @richardlau, this shouldn't be fast-tracked.

@BridgeAR
Copy link
Member Author

Thanks :) I just added it because it already had a lot of LGs.

I am somewhat puzzled why the linter failed.

@joyeecheung
Copy link
Member

It's possible that the master branch has been force-pushed since this PR branched. Can you do a rebase and try again? @BridgeAR

Currently the documentation is not specific how fast-tracking should
be applied. This specifies exactly how things should be done to prevent
confusion.
@BridgeAR BridgeAR force-pushed the specifiy-fast-tracking branch from 85251b1 to c0c5247 Compare September 18, 2018 14:57
@BridgeAR
Copy link
Member Author

CI testing is done.
`fast-track` and add a comment that collaborators may upvote. Please mention the
collaborators that gave an approval before in that comment. If someone disagrees
with the fast-tracking request, please go ahead and remove the label and leave a
Copy link
Member

Choose a reason for hiding this comment

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

Nit: remove go ahead and

Copy link
Member

Choose a reason for hiding this comment

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

Nit part two: probably remove please in this sentence too. Just this?:

If someone disagrees with the fast-tracking request, remove the label and leave a comment...

@danbev
Copy link
Contributor

danbev commented Sep 21, 2018

Landed in 54af973.

@danbev danbev closed this Sep 21, 2018
danbev pushed a commit that referenced this pull request Sep 21, 2018
Currently the documentation is not specific how fast-tracking should
be applied. This specifies exactly how things should be done to prevent
confusion.

PR-URL: #22929
Reviewed-By: Denys Otrishko <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: John-David Dalton <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Weijia Wang <[email protected]>
Reviewed-By: Richard Lau <[email protected]>
Reviewed-By: Matheus Marchini <[email protected]>
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: Yuta Hiroto <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
Reviewed-By: George Adams <[email protected]>
targos pushed a commit that referenced this pull request Sep 21, 2018
Currently the documentation is not specific how fast-tracking should
be applied. This specifies exactly how things should be done to prevent
confusion.

PR-URL: #22929
Reviewed-By: Denys Otrishko <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: John-David Dalton <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Weijia Wang <[email protected]>
Reviewed-By: Richard Lau <[email protected]>
Reviewed-By: Matheus Marchini <[email protected]>
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: Yuta Hiroto <[email protected]>
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
Reviewed-By: George Adams <[email protected]>
@BridgeAR BridgeAR deleted the specifiy-fast-tracking branch January 20, 2020 11:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.