diff options
Diffstat (limited to 'patching.md')
| -rw-r--r-- | patching.md | 43 |
1 files changed, 0 insertions, 43 deletions
diff --git a/patching.md b/patching.md deleted file mode 100644 index 0c616c3..0000000 --- a/patching.md +++ /dev/null @@ -1,43 +0,0 @@ -# Patch Acceptance Process - -- PRs that change or add behavior are not accepted without being tied to an - issue. Most fixes, even if you think they are obvious, require an issue - too. Almost every change breaks someone who has depended on the behavior, - even broken behavior. -- Significant changes need a design document. Please create an issue describing - the proposed change, and post a link to it to rules-pkg-discuss@googlegroups.com. - Wait for discussion to come to agreement before proceeding. -- Features and bug fixes should be as portable as possible. - - do not not disable tests on Windows because it is convenient for you - - if a feature is only available on specific platforms, it must be optional. That - is, it requires a distinct bzlmod MODULE -- All fixes and features must have tests. -- Ensure you've signed a [Contributor License - Agreement](https://cla.developers.google.com). -- Send us a pull request on - [GitHub](https://github.com/bazelbuild/rules_pkg/pulls). If you're new to GitHub, - read [about pull - requests](https://help.github.com/articles/about-pull-requests/). Note that - we restrict permissions to create branches on the main repository, so - you will need to push your commit to [your own fork of the - repository](https://help.github.com/articles/working-with-forks/). -- Wait for a repository owner to assign you a reviewer. We strive to do that - within 4 business days, but it may take longer. If your review gets lost - you can escalate by starting a thread on - [GitHub Discussions](https://github.com/bazelbuild/bazel/discussions). -- Work with the reviewer to complete a code review. For each change, create a - new commit and push it to make changes to your pull request. -- A maintainer will approve the PR and merge it. - -Tips -- Large PRs are harder to review. If you have to refactor code to implement a feature - please split that into at least 2 PRs. The first to refactor without changing behavior - and the second to implemtn the new behavior. Of course, as above, any PR that large - should be discussed in an issue first -- Please do not send PRs that update dependencies (WORKSPACE or MODULE.bzl) just to - stay at head. We try to maintain backwards compatibility to LTS releases as long as - possible, so we only update to new versions of dependencies when it is required. - -For further information about working with Bazel and rules in general: -- Read the [Bazel governance plan](https://www.bazel.build/governance.html). -- Read the [contributing to Bazel](https://www.bazel.build/contributing.html) guide. |