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.

Sign up for GitHub

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: examples for fast-tracking regression fixes #17379

Closed
wants to merge 1 commit into from
Closed

doc: examples for fast-tracking regression fixes #17379

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions COLLABORATOR_GUIDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -122,12 +122,14 @@ Before landing pull requests, sufficient time should be left for input
from other Collaborators. In general, leave at least 48 hours during the
week and 72 hours over weekends to account for international time
differences and work schedules. However, certain types of pull requests
can be fast-tracked and may be landed after a shorter delay:

* Focused changes that affect only documentation and/or the test suite.
`code-and-learn` and `good-first-issue` pull requests typically fall
into this category.
* Changes that fix regressions.
can be fast-tracked and may be landed after a shorter delay. For example:

* Focused changes that affect only documentation and/or the test suite:
* `code-and-learn` tasks typically fall into this category.
* `good-first-issue` pull requests may also be suitable.
Copy link
Member

Choose a reason for hiding this comment

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

How about:

Pull requests from new contributors (for example code-and-learn tasks) that are low-risk and uncontentious.

  • If the aim is to improve the experience of your first node contribution, then let's say that specifically.
  • If we say docs or tests only, does that cover source comments? Or whitespace fixes? I feel like specifying the "what" is going to be too complex, but the "why" might be easier.

* Changes that fix regressions:
* Regressions that break the workflow (red CI or broken compilation).
* Regressions that happen right before a release, or reported soon after.
Copy link
Member

Choose a reason for hiding this comment

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

Maybe: "Fixes that need to be backported to a release line urgently."

If it's reported soon after a release and we decided to leave it till the next one, then it doesn't need to be fast-tracked IMO.

Copy link
Member

@joyeecheung joyeecheung Nov 30, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

I think this is just listing changes that "can be" fast-tracked, not necessarily "need to be"?


When a pull request is deemed suitable to be fast-tracked, label it with
`fast-track`. The pull request can be landed once 2 or more collaborators
Expand Down