gianm commented on a change in pull request #7279: Add committer_readme.md URL: https://github.com/apache/incubator-druid/pull/7279#discussion_r267140272
########## File path: committer_readme.md ########## @@ -0,0 +1,56 @@ + +## PR action item checklist for committers + +1. Add appropriate tags to the PR, in particular: + + - **`Design Review`** - for changes that will be hard to undo after they appear in some Druid release, and/or + changes that will have lasting consequences in the codebase. Examples: + - Major architectural changes or API changes + - Adding new or changing behaviour of existing query types (e. g. changing and algorithm behind some query type + or changing from floating point to double precision) + - Adding new or changing existing HTTP requests and responses (e. g. a new HTTP endpoint) + - Adding new or changing existing interfaces for extensions (`@PublicApi` and `@ExtensionPoint`) + - Adding new or changing existing server configuration parameter (e. g. altering the behavior of a config + parameter) + - Adding new or changing existing emitted metrics + - Other major changes + + The PR description should succintly, but completely list all public API elements (@PublicApi or @ExtensionPoint), + configuration options, emitted metric names, HTTP endpoint paths and parameters that are added or changed in the + PR. If they are not listed, ask the PR author to update the PR description. + + - **`Incompatible`** - for changes that may change the behaviour of Druid clusters if a new version of Druid with + the subject change is rolled out, unless some server or query configurations are altered, or break Druid extensions + on the source level because extensions API is changed. See examples above, in the section describing the + `Design Review` tag. + + All `Incompatible` PRs should be tagged `Design Review` too, but not vice versa: some `Design Review` issues, + proposals and PRs may not be `Incompatible`. + + - **`Release Notes`** - for important changes that should be reflected in the next Druid’s version release notes. + Critically, those are changes that require some server or query configuration changes made by Druid cluster + operators to preserve the former cluster behaviour, i. e. the majority of PRs tagged `Incompatible`. However, some + `Incompatible` PRs may not need to be tagged `Release Notes`, e. g. PRs that only change some extension APIs, + because when building extensions with the newer Druid version the incompatibility will be discovered anyway. + + Secondarily, PRs that add new features, improve performance or improve Druid cluster operation experience could + also be tagged `Release Notes` at your discretion. + + - **`Bug`** / **`Security`** / **`Feature`** / **`Performance`** / **`Refactoring`** / **`Improvement`** - can be + used to distinguish between types of changes. **`Compatibility`** tag also falls into this category, it’s + specifically for PRs that restore or improve compatibility with previous Druid versions if it was inadvertently + broken, or for changes that ensure forward compatibility with future Druid versions, forseening specific changes + that would otherwise break the compatibility. + + - **`Development Blocker`** - for changes that need to be merged before some other PRs could even be published. + `Development Blocker` PRs should be prioritized by reviewers, so that they could be merged as soon as possible, + thus not blocking somebody's work. + + - Consider adding one or several **`Area -`** tags. Consider creating a new `Area -` tag if none of the existing + `Area` tags is applicable to the PR. + +2. Consider adding `Bug` and `Security` PRs to the next Druid milestone. Don't add PRs that are neither `Bug` nor Review comment: Add some rationale? Maybe: > Consider adding any `Bug` and `Security` PRs to the next Druid milestone whenever they are important enough to fix before the next release. This ensures that they will be considered by the next release manager as potential release blockers. Please don't add PRs that are neither `Bug` nor `Security`-related to milestones until after they are committed, to avoid cluttering the release manager's workflow. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@druid.apache.org For additional commands, e-mail: commits-h...@druid.apache.org
