1. 15 7月, 2022 1 次提交
  2. 02 7月, 2022 1 次提交
  3. 29 6月, 2022 1 次提交
    • A
      bpf, docs: Better scale maintenance of BPF subsystem · 32df6fe1
      Alexei Starovoitov 提交于
      The BPF subsystem consists of a large number of pieces. There is not a
      single person that understands it all. Yet reviews are crucially important
      for the BPF community to provide productive quality feedback to contributors
      in a timely manner and therefore to ultimately expand the number of active
      developers in the community.
      
      So far, the BPF community had a two-stage review system, that is, a weekly
      rotation among 7 developers (Alexei, Daniel, Andrii, Martin, Song, Yonghong,
      John) as a first-level review of all inbound patches accompanied by a BPF CI
      system which runs the in-tree BPF selftests to check for regressions for
      every new patch, and then, a final check by Alexei, Daniel, Andrii to apply
      the patches to either bpf or bpf-next trees.
      
      This system worked well for the last ~3.5 years, but clearly reaches its
      limits these days as it does not scale enough. Especially, as we also need
      to allow enough room for every developer to contribute patches themselves,
      integrate with their day to day job, and in particular avoid burnout. We
      want to better scale both horizontally and vertically going forward.
      
      On the horizontal scale, we are adding more developers (KP, Stan, Hao, Jiri)
      to the overall core reviewer team, thus growing to 11 people in total. The
      weekly rotation for the horizontal oncall reviewer is shortened to 1/2 week
      (Mo - Wed and Thur - Fri). Instead of just patches, the coverage however
      extends also generally to triage and reply to mailing list traffic (e.g. RFCs,
      questions, etc).
      
      On the vertical scale, there is clearly a need for deep expertise areas to
      assign dedicated maintainer/reviewer teams that are responsible for code
      reviews and help with design of individual building blocks. To some degree
      we have been doing this implicitly, but the point is to formalize the teams
      and commitment.
      
      There is an overlap between areas and boundaries are intentionally grey. These
      additional entries provide a guidance on who has to look at the patches. The
      patch series which span multiple areas will be looked at by multiple people.
      The vertical review with areas of deep expertise are bundled at the same time
      with the horizontal side.
      
      This patch cleans up a bit the BPF entries, adds mentioned developers to
      the horizontal scale and creates new sub-entries with teams for developers
      committing to the above outlined vertical scale. Also, pw.git tools we use
      for BPF tree maintenance have been updated with a new pw-schedule script to
      semi-automate vertical oncall review rotation.
      Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NMartin KaFai Lau <martin.lau@linux.dev>
      Acked-by: NSong Liu <song@kernel.org>
      Acked-by: NYonghong Song <yhs@fb.com>
      Acked-by: NMykola Lysenko <mykolal@fb.com>
      Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Acked-by: NKP Singh <kpsingh@kernel.org>
      Acked-by: NStanislav Fomichev <sdf@google.com>
      Acked-by: NHao Luo <haoluo@google.com>
      Acked-by: NQuentin Monnet <quentin@isovalent.com>
      Link: https://git.kernel.org/pub/scm/linux/kernel/git/dborkman/pw.git
      Link: https://lore.kernel.org/bpf/5bdc73e7f5a087299589944fa074563cdf2c2c1a.1656353995.git.daniel@iogearbox.net
      32df6fe1
  4. 28 6月, 2022 1 次提交
  5. 26 6月, 2022 1 次提交
  6. 24 6月, 2022 5 次提交
  7. 23 6月, 2022 1 次提交
  8. 21 6月, 2022 1 次提交
  9. 18 6月, 2022 1 次提交
  10. 17 6月, 2022 6 次提交
  11. 16 6月, 2022 1 次提交
  12. 15 6月, 2022 1 次提交
  13. 14 6月, 2022 1 次提交
  14. 13 6月, 2022 2 次提交
  15. 10 6月, 2022 1 次提交
  16. 09 6月, 2022 4 次提交
  17. 08 6月, 2022 2 次提交
  18. 07 6月, 2022 5 次提交
  19. 06 6月, 2022 2 次提交
  20. 03 6月, 2022 2 次提交