diff options
author | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-07-20 19:26:21 +0100 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-07-24 16:33:46 +0100 |
commit | a926dd6cdd66ada6febf9638a1916dc988c6e1c8 (patch) | |
tree | ce93eedc510c14f4e3b086ab7e0f964f1ec62a7e | |
parent | 17aabc0127435fc071ed390b09e702dfe2d43cb8 (diff) | |
download | poky-a926dd6cdd66ada6febf9638a1916dc988c6e1c8.tar.gz |
Add MAINTAINERS.md file
We have a long history with maintainers files and good and bad experiences. There
are people who'd like to see a kernel style machine readable file which defines
exactly which people should be reviewing which areas. In practise, the files we
do have struggle to stay up to date (e.g. the recipe maintainers file) and such
a file would also cause conflicts of expectations where person X would want to be
cc'd on patches touching file Y and want a revert if they hadn't acked it. We also
don't have clearly defined boundaries in some areas, e.g. toolchain.
We have a wide peer review system and nobody gets to make changes without that
review, even myself as the lead for OE-Core/Bitbake.
I do want to recognise that some people are key experts on particular areas and
hightlight that their views on those areas do carry weight. With that also comes
repsonsibility to help try and figure out bugs, help with review and so on.
I've tried to strike a balance with this file to detail who some of the experts
for particular areas are and to also highlight where we don't have coverage and
that there are opportunities.
I've tried to put the file in the wider context of the project, not just OE-Core.
It is in a repo rather than a wiki so we have visibility to changes through the
change control process.
I'm sure I will miss people, sorry, it is inevitable when you try and make a
list. There may be people who want to step down and don't want to be in this
role, I'm also hoping there are going to be some new volunteers to help in some
areas. Please do send follow up updates, this patch is really meant to help get
us started.
Volunteers to maintainer specific areas of the project are very welcome and
feel free to reach out to ask about areas or getting started and working towards
an official maintainer role (e.g. help with bug fixing).
(From OE-Core rev: b629978efae35d5ea3821f4375bc0d8228b6cc26)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-rw-r--r-- | MAINTAINERS.md | 71 |
1 files changed, 71 insertions, 0 deletions
diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 0000000000..604d800f63 --- /dev/null +++ b/MAINTAINERS.md | |||
@@ -0,0 +1,71 @@ | |||
1 | OpenEmbedded-Core and Yocto Project Maintainer Information | ||
2 | ========================================================== | ||
3 | |||
4 | OpenEmbedded and Yocto Project work jointly together to maintain the metadata, | ||
5 | layers, tools and sub-projects that make up their ecosystems. | ||
6 | |||
7 | The projects operate through collaborative development. This currently takes | ||
8 | place on mailing lists for many components as the "pull request on github" | ||
9 | workflow works well for single or small numbers of maintainers but we have | ||
10 | a large number, all with different specialisms and benefit from the mailing | ||
11 | list review process. Changes therefore undergo peer review through mailing | ||
12 | lists in many cases. | ||
13 | |||
14 | This file aims to acknowledge people with specific skills/knowledge/interest | ||
15 | both to recognise their contributions but also empower them to help lead and | ||
16 | curate those components. Where we have people with specialist knowledge in | ||
17 | particular areas, during review patches/feedback from these people in these | ||
18 | areas would generally carry weight. | ||
19 | |||
20 | This file is maintained in OE-Core but may refer to components that are separate | ||
21 | to it if that makes sense in the context of maintainership. The README of specific | ||
22 | layers and components should ultimately be definitive about the patch process and | ||
23 | maintainership for the component. | ||
24 | |||
25 | Recipe Maintainers | ||
26 | ------------------ | ||
27 | |||
28 | See meta/conf/distro/include/maintainers.inc | ||
29 | |||
30 | Component/Subsystem Maintainers | ||
31 | ------------------------------- | ||
32 | |||
33 | * Kernel (inc. linux-yocto, perf): Bruce Ashfield | ||
34 | * Reproducible Builds: Joshua Watt | ||
35 | * Toaster: David Reyna | ||
36 | * Hash-Equivalence: Joshua Watt | ||
37 | * Recipe upgrade infrastructure: Alex Kanavin | ||
38 | * Toolchain: Khem Raj | ||
39 | * ptest-runner: Aníbal Limón | ||
40 | * opkg: Alex Stewart | ||
41 | |||
42 | Maintainers needed | ||
43 | ------------------ | ||
44 | |||
45 | * Pseudo | ||
46 | * Layer Index | ||
47 | * recipetool | ||
48 | * QA framework/automated testing | ||
49 | * error reporting system/web UI | ||
50 | * wic | ||
51 | * Patchwork | ||
52 | * Patchtest | ||
53 | * Prelink-cross | ||
54 | * Matchbox | ||
55 | * Sato | ||
56 | * devtool | ||
57 | * eSDK | ||
58 | * Autobuilder | ||
59 | |||
60 | Layer Maintainers needed | ||
61 | ------------------------ | ||
62 | |||
63 | * meta-gplv2 (ideally new strategy but active maintainer welcome) | ||
64 | |||
65 | Shadow maintainers/development needed | ||
66 | -------------------------------------- | ||
67 | |||
68 | * toaster | ||
69 | * bitbake | ||
70 | |||
71 | |||