[GitHub] [incubator-druid] gianm commented on a change in pull request #7279: Add committer_readme.md

[GitBox <gi...@apache.org>]

gianm commented on a change in pull request #7279: Add committer_readme.md
URL: https://github.com/apache/incubator-druid/pull/7279#discussion_r267142800
 
 

 ##########
 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
 
 Review comment:
   IMO we should loosen a bit from "may change the behaviour of Druid clusters". Lots of changes may change the behavior of Druid clusters in various ways (minor perf changes, memory usage changes, & so on) but not all of them are really incompatible. How about a definition like:
   
   > Changes that alter public API elements (`@PublicApi` or `@ExtensionPoint`), runtime configuration options, emitted metric names, HTTP endpoint behavior, or server behavior in some way that affects one of the following:
   >
   > - Ability to do a rolling update as documented on http://druid.io/docs/latest/operations/rolling-updates.html without needing any modifications to server configurations or query workload.
   > - Ability to roll back a Druid cluster to a prior version.
   > - Ability to continue using old Druid extensions without recompiling them.
   >
   > If a Druid release contains any "Incompatible" changes then it should have a second-digit version bump (i.e. from 0.10 -> 0.11).
   >
   > Note that no matter what, we must support the ability to do a rolling update _somehow_ (even if some special care is needed), and the ability to roll back to at least the immediate prior Druid version. If a change makes either one of these impossible then it should be re-designed.

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org