kou commented on code in PR #33660: URL: https://github.com/apache/arrow/pull/33660#discussion_r1080723781
########## docs/source/developers/reviewing.rst: ########## @@ -255,3 +255,43 @@ Social aspects * Like any communication, code reviews are governed by the Apache `Code of Conduct <https://www.apache.org/foundation/policies/conduct.html>`_. This applies to both reviewers and contributors. + + +Labelling +========= + +While reviewing PRs, we should try to identify whether the corresponding issue +needs to be marked with one or both of the following issue labels: + +* **Critical Fix**: The change fixes either: (a) a security vulnerability; + (b) a bug that causes incorrect or invalid data to be produced; + or (c) a bug that causes a crash (while the API contract is upheld). + This is intended to mark fixes to issues that may affect users without their + knowledge. For this reason, fixing bugs that cause errors don't count, since + those bugs are usually obvious. Bugs that cause crashes are considered critical + because they are a possible vector of Denial-of-Service attacks. +* **Breaking Change**: The change breaks backwards compatibility in a public API. + For changes in C++, this does not include changes that simply break ABI + compatibility, except for the few places where we do guarantee ABI Review Comment: Why do we not include ABI compatibility? I think that we need to bump major version when we break API or ABI compatibility. I thought that we use "Breaking Change" to determine whether we should bump major/minor version. BTW, we will be able to check ABI compatibility automatically by CI. (Some projects do it.) So we may not check ABI compatibility manually. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
