[PATCH] D89918: Fix issue: clang-format result is not consistent if "// clang-format off" is followed by macro definition.

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 29 12:58:38 PDT 2023


aaron.ballman added a comment.

In D89918#4460401 <https://reviews.llvm.org/D89918#4460401>, @MyDeveloperDay wrote:

> @owenpan @HazardyKnusperkeks @rymiel what are your feeling on how we should close old clang-format reviews like this?  (@aaron.ballman any thoughts on how it should be done?)
>
> we end up with lots of reviews that either get metaphorically abandoned, (without actually being abandoned).. should we have some sort of rule, that says reviews left for N months with no activity are automatically abandoned (to do this you have to comindeer the revision, which I don't like doing)
>
> Part of me just wants to consume the unit tests (if they pass).. do you think we should do anything? what about issues we effectively are saying "no to" like D147969 <https://reviews.llvm.org/D147969> but are then not abandoned by the author?

I don't think we have any sort of community policy on how to handle this, it's basically a case by case basis. If someone submits a patch and then (explicitly or implicitly) abandons the work, I believe it is acceptable to grab changes of value out of the patch and apply them to the code base as you see fit (the user contributing the patch expected their changes to make it in to the project, so I doubt anyone would be upset in practice). I would recommend linking to the review where the code originated from when committing the changes so there's good attribution for the commit.

To handle the review itself, you can commandeer the patch to abandon it or you can resign as a reviewer from the revision, but that's about the only two ways I know of to address that. Both approaches have social pressure (commandeering or resigning are not the easiest decisions for folks to make), so my guess is this will be inconsistently handled which suggests that resigning from the revision is the better approach to prefer as that gets you the work queue you want without requiring others to play along consistently. But I think either approach is acceptable -- I've seen folks do it both ways.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89918/new/

https://reviews.llvm.org/D89918



More information about the cfe-commits mailing list