5799 2014-02-07 04:04:40 +0000 add standardized MAINTAINERS infrastructure 2025-06-26 14:57:11 +0000 1 1 7 Build System, Metadata & Runtime OE-Core configuration unspecified x86 Multiple NEW Low enhancement Future 1 trevor.woerner richard.purdie otavio randy.macleod sgw --- --- Yes (doc changes required) oldest_to_newest 40219 0 trevor.woerner 2014-02-07 04:04:40 +0000 http://article.gmane.org/gmane.comp.handhelds.openembedded.core/47894 There currently is no standardized way in which layers keep lists of component maintainers. The Yocto project provides a "recipe" file "meta-poky/meta-yocto/conf/distro/include/maintainers.inc" and various other layers haphazardly try to include maintainership information in various configuration files (e.g. meta-fsl-arm-extra/conf/machine/cfa10036.conf). But there is a standardized way for a project to keep track of its maintainers: by using a top-level MAINTAINERS file. A MAINTAINERS file is standardized, and includes many useful clauses to indicate maintainership in various ways. For example maintainership can extend to a directory, a directory plus everything below it, or just a file. Provisions are available to also include websites and multiple maintainers. The nice thing about having a MAINTAINERS file is the ability to use a "get_maintainer.pl" script to look through patches (before submission) to suggest lists of people to CC. In addition to sending a patch to the mailing list, such a script can parse the standardized MAINTAINERS file to discover addition people who might be interested in learning of patches to their areas of interest. This script is also able to use "git blame" in order to find other potential parties interested in a given patch by creating a list of the people who have modified in the past the lines of code being modified by a given patch. This issue was discussed at the last OE TSC meeting (Feb 2014). Most were in favour, but there were comments that a MAINTAINERS file might lead some to believe patches could not be applied without a MAINTAINERS "okay". I'm creating this issue to track this discussion. The patch linked to at the start of this issue is an example of a "get_maintainer.pl" script I adjusted from the Linux kernel code-base to add support for its inclusion in the OE project. Also, see the MAINTAINERS file from the Linux kernel for information regarding its syntax. 40220 1 trevor.woerner 2014-02-07 04:05:22 +0000 Richard, it was decided at the end of the TSC meeting that we'd like you to make a decision on this issue. 40221 2 trevor.woerner 2014-02-07 04:08:24 +0000 In retrospect, I should have probably named my proposed script "get_oe_maintainer.pl" so it doesn't collide with the similar (but slightly different) "get_maintainer.pl" script from the Linux kernel sources. 40660 3 richard.purdie 2014-02-25 10:03:08 +0000 I'm afraid I have my doubts about whether this makes sense. The kernel has grown in a particular way and therefore adopted particular conventions to handle that. In some ways OE faces the same problem but it also faces it quite differently too, for example we decided to scale with layers instead. The model is that each layer has a maintainer or small number of maintainers and its those people who gate the changes. Yes, for OE-Core, there is a mechanism for a notion of someone responsible for a given recipe but that convention is specific to OE-Core and in general has not worked well for the wider OE metadata when we've tried it in the past. The metadata we use against OE-Core isn't even in OE-Core, its in poky. That was done to clearly show that this was a way one of the derivative distros maintained things, it wasn't meant to be part of the core, its more of a housekeeping mechanism. I think the notion of a maintainer script will trigger all kinds of user confusion type issues since it will sometimes give good information and sometimes give very bad info. The maintainer is the person(s) listed in the READM (as per the Yocto Project Compatible Guidelines). I'd therefore really like to take a step back here and ask "what problem are we trying to solve?" and "does it really need solving? Does this solution make sense?". 40845 4 trevor.woerner 2014-03-03 20:57:21 +0000 > I'd therefore really like to take a step back here and ask "what problem are > we trying to solve?" and "does it really need solving? Does this solution > make sense?". Succinctly, the two problems I was hoping to address are: 1) I think patches are more likely to get reviewed and perhaps they might get better reviews if the most relevant people are CCed (i.e. both the official maintainer(s), and the people who have most recently made changes to the parts of the project touched by the patch). 2) The declaration of who is maintaining various portions of the project isn't standardized or located somewhere obvious. By opening this issue, I'm not suggesting these are huge problems for this project (considering the volume of patches, this project actually does quote a good job!). I suggested this issue more as a tweak to the existing process which I hope would improve patch review a little bit. 43520 5 otavio 2014-05-22 19:03:27 +0000 I think I second Trevor's view. Having patches being sent to people who has contributed to it and to the maintainer may increase the review quality quite a bit. 43666 6 richard.purdie 2014-05-29 15:26:39 +0000 Info added -> New state 75007 7 richard.purdie 2017-07-13 15:29:31 +0000 There has been various discussions about this but no decision or consensus as yet.