Commit c42ab4d2 authored by Daniel Vetter's avatar Daniel Vetter
Browse files

CONTRIBUTING: formalize review rules

There's a bunch of reasons why I think we should formalize and enforce
our review rules for igt patches:

- We have a lot of new engineers joining and review helps enormously
  with mentoring and learning. But right now only patches from
  contributors without commit rights are consistently subjected to
  review, which makes this imbalanced and removes senior contributors
  from the review pool.

- We have a much bigger team and we need to make sure we're aligned on
  where igt as a tool and testsuite needs to head towards. Getting
  that alignment happens through reviewing each other's submission.
  Pushing a contentious patch and then dealing with a heated irc
  discussion is much less effective.

- Finally igt becomes ever more important for our testing, making sure
  the code quality is high is important. Review helps with that.

v2: Improve wording a bit (Imre).
Acked-by: Daniel Stone's avatarDaniel Stone <>
Acked-by: Jani Nikula's avatarJani Nikula <>
Acked-by: Joonas Lahtinen's avatarJoonas Lahtinen <>
Acked-by: default avatarMaarten Lankhorst <>
Acked-by: Petri Latvala's avatarPetri Latvala <>
Acked-by: Imre Deak's avatarImre Deak <>
Acked-by: Robert Foss's avatarRobert Foss <>
Acked-by: Ben Widawsky's avatarBen Widawsky <>
Acked-by: Tvrtko Ursulin's avatarTvrtko Ursulin <>
Acked-by: default avatarMika Kuoppala <>
Acked-by: default avatarArkadiusz Hiler <>
Acked-by: Emma Anholt's avatarEric Anholt <>
Acked-by: Lionel Landwerlin's avatarLionel Landwerlin <>
Acked-by: Lyude Paul's avatarLyude <>
Signed-off-by: Daniel Vetter's avatarDaniel Vetter <>
parent a865fee5
......@@ -26,10 +26,11 @@ A short list of contribution guidelines:
convenience macros provided by the igt library. The semantic patch lib/igt.cocci
can help with the more automatic conversions.
- There is no formal review requirement and regular contributors with commit
access can push patches right after submitting them to the mailing lists. But
invasive changes, new helper libraries and contributions from newcomers should
go through a proper review to ensure overall consistency in the codebase.
- Patches need to be reviewed on the mailing list. Exceptions only apply for
testcases and tooling for drivers with just a single contributor (e.g. vc4).
In this case patches must still be submitted to the mailing list first.
Testcase should preferrably be cross-reviewed by the same people who write and
review the kernel feature itself.
- When patches from new contributors (without commit access) are stuck, for
anything related to the regular releases, issues with packaging and
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment