How do we review changes made with coccinelle?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar recently sent a series that made pretty extensive use of coccinelle
to remove a lot of the_repository [1], but then we ended up in this
weird spot where even though several reviewers thought the code changes
looked good, we weren't sure about giving Reviewed-By because we didn't
know coccinelle or how to review it.

I'm pretty sure that the series could have been merged without a hitch
if reviewers knew what to do about coccinelle. I expect more of these to
appear as a result of the libification work, so it's probably a good
time for us to figure out some norms about coccinelle :)

Perhaps we could start the discussion by sharing thoughts on the
following questions, which I'll summarize in a change to
contrib/coccinelle/README (where we can do final bikeshedding):

- Is it okay to give Reviewed-By on the basis of _just_ the in-tree
  changes and ignore the .cocci patch?

  - If not, what should reviewers look for in .cocci? Do we have a
    style?

- When do we introduce .pending.cocci vs .cocci?

- What do we do with .cocci after they've been applied?

- Do we care about new patches slowing down coccicheck?

Relevant threads
- How to learn cocci: https://lore.kernel.org/git/230326.86edpcw0yh.gmgdl@xxxxxxxxxxxxxxxxxxx/ 
- https://lore.kernel.org/git/230328.86a5zxw31u.gmgdl@xxxxxxxxxxxxxxxxxxx/
- https://lore.kernel.org/git/230326.86ileow1fu.gmgdl@xxxxxxxxxxxxxxxxxxx/

[1] https://lore.kernel.org/git/cover-v2-00.17-00000000000-20230328T110946Z-avarab@xxxxxxxxx/




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux