Skip to content

Latest commit

 

History

History
100 lines (82 loc) · 3.59 KB

onboarding-extras.md

File metadata and controls

100 lines (82 loc) · 3.59 KB
Raw

Additional Onboarding Information

Labels

Subsystems

  • lib/*.js (assert, buffer, etc.)
  • build
  • doc
  • lib / src
  • test
  • tools

There may be more than one subsystem valid for any particular issue or pull request.

General

  • confirmed-bug - Bugs you have verified exist
  • discuss - Things that need larger discussion
  • feature request - Any issue that requests a new feature (usually not PRs)
  • good first issue - Issues suitable for newcomers to process
  • meta - For issues whose topic is governance, policies, procedures, etc.
  • tsc-agenda - Open issues and pull requests with this label will be added to the Technical Steering Committee meeting agenda
  • author-ready - A pull request is author ready when:
    • There is a CI run in progress or completed.
    • There is at least one Collaborator approval (or two TSC approvals for semver-major PRs).
    • There are no outstanding review comments.

Please always add the author ready label to the pull request in that case. Please always remove it again as soon as the conditions are not met anymore, such as if CI run fails or a new outstanding review comment is posted.

  • semver-{minor,major}

    • be conservative – that is, if a change has the remote chance of breaking something, go for semver-major

    • when adding a semver label, add a comment explaining why you're adding it

    • minor vs. patch: roughly: "does it add a new method / does it add a new section to the docs"

    • major vs. everything else: run last versions tests against this version, if they pass, probably minor or patch

    • A breaking change helper (full source):

      SHOW=$(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')
git checkout $(git show -s --pretty='%T' $SHOW) -- test
make -j4 test

LTS/Version labels

We use labels to keep track of which branches a commit should land on:

  • dont-land-on-v?.x
    • For changes that do not apply to a certain release line
    • Also used when the work of backporting a change outweighs the benefits
  • land-on-v?.x
    • Used by releasers to mark a PR as scheduled for inclusion in an LTS release
    • Applied to the original PR for clean cherry-picks, to the backport PR otherwise
  • backport-requested-v?.x
    • Used to indicate that a PR needs a manual backport to a branch in order to land the changes on that branch
    • Typically applied by a releaser when the PR does not apply cleanly or it breaks the tests after applying
    • Will be replaced by either dont-land-on-v?.x or backported-to-v?.x
  • backported-to-v?.x
    • Applied to PRs for which a backport PR has been merged
  • lts-watch-v?.x
    • Applied to PRs which the LTS working group should consider including in a LTS release
    • Does not indicate that any specific action will be taken, but can be effective as messaging to non-collaborators
  • lts-agenda
    • For things that need discussion by the LTS working group
    • (for example semver-minor changes that need or should go into an LTS release)
  • v?.x
    • Automatically applied to changes that do not target master but rather the v?.x-staging branch

Once a release line enters maintenance mode, the corresponding labels do not need to be attached anymore, as only important bugfixes will be included.

Other Labels

  • Operating system labels
    • macos, windows, smartos, aix
    • No linux, linux is the implied default
  • Architecture labels
    • arm, mips, s390, ppc
    • No x86{_64}, since that is the implied default