<div dir="ltr"><div bgcolor="#ffffff" text="#2e3436" link="#2a76c6" vlink="#2e3436"><div>All,</div><div><br></div><div>I think this topic is somewhat tied into the OE layer quality discussion, but different enough that I though it warranted its own thread. I wasn&#39;t sure if I should post here or openembedded-devel. Someone can loop that list in if they think it is necessary.<br></div><div><br></div><div>I would like to open up the discussion about the possibility of reworking the way recipe maintainers are currently tracked. I discussed this briefly at the ELC with a few, and it was already discussed previously in [1] but I think that thread was originally focused on a different topic.</div><div><br></div><div>I&#39;ll start off with a few places where I think the current OE-core maintainers.inc behaviour could be improved, or is lacking. These are in no particular order, and I&#39;m not necessarily proposing we have to address all of them:<br><br></div><div> 1) My understanding is that it is difficult to assign maintainers in layers outside of OE-core in a manner that is consistent with OE-core (they can of course do their own thing if they want, but that doesn&#39;t really relate to this discussion).<br><br></div><div> 2) Current maintainership outside of OE-core seems to be pretty much per-layer. IMHO, this might not be fine grained enough and stressful on the maintainers? For example, as a new person looking to help out, I might not want to sign up to maintain a whole *layer* per-se, but would probably feel comfortable tackling a few recipes.<br><br></div><div> 3) There is currently no mechanism for having a maintainer for things other than recipes (e.g. bbclass files, python libraries, scripts, etc). For example, I personally would volunteer to take over ownership of waf.bbclass and icecc.bbclass if such a thing were possible.</div><div><br><br></div><div>A few possible paths forward are listed below, along with some pros and cons. I&#39;m not necessarily advocating one over the other, but just listing options, please chime in with more options, or other pros/cons.<br></div><div><br></div><div> 1) Do nothing. </div><div>Perhaps the above concerns aren&#39;t sufficiently important to warrant any changes.</div><div><br></div><div> 2) Move the MAINTAINER variable out of maintainers.inc into each recipe.</div><div>This would potentially solve the problem of assigning maintainers outside of OE-core. It might require some changes to RSS [2] as discussed previously in [1]. There was some agreement for this in said discussion. This wouldn&#39;t allow for listing the maintainers of other (non-recipe) files. I&#39;ve heard arguments that having the maintainers distributed across recipes makes them harder to maintain (e.g. they get out of date), but I&#39;ve also heard the argument that having them centralized is harder to maintain.<br></div><div><br></div><div> 3) Switch to a Linux Kernel style MAINTAINERS file</div><div>I&#39;ve seen this one proposed in a previous discussion (can&#39;t find the link right now). This file format already has some tooling around it, making it easy to integrate with git send-email and such, and can track some ot<span id="m_7755332489571255702-x-evo-selection-start-marker"></span><span id="m_7755332489571255702-x-evo-selection-end-marker"></span>her useful attributes about the file (e.g. what the level of maintainership is). However, it would certainly require changes to RSS, and some work if it is determined we also need that information to be extracted to per-recipe bitbake variables since the current tooling is in perl. This would allow maintainers to be listed for things other than recipes.</div><div><br></div><div> 4) Add the ability for other layers to specify their own maintainer.inc files... something like a BBLAYER_MAINTAINERS variable?<br></div><div><br><br></div><div>And now, for my personal opinion:<br></div><div><br></div><div>I think that option #2 or #3 would be the best, as I really do think it might be a big help to the current layer maintainers to be able to part out maintainership in a more fine grained manner (would any of the actual layer maintainers be able to comment?). #2 is probably the easiest, but #3 is by far the most expressive and possibly the most helpful for the actual maintainers? In any event, I&#39;m willing to devote some time to working on this. In the event #3 is chosen, I would even be willing to write a python parser for the Kernel MAINTAINERS file format so that bitbake can pick internally pick up the maintainer state. It sounds like a fun challenge....<br></div><div><br></div><div>Thanks,</div><div>Joshua Watt</div><div><br></div><div>[1] <a href="http://lists.openembedded.org/pipermail/openembedded-architecture/2018-February/000700.html" target="_blank">http://lists.openembedded.org/<wbr>pipermail/openembedded-<wbr>architecture/2018-February/<wbr>000700.html</a></div><div>[2] <a href="http://recipes.yoctoproject.org" target="_blank">http://recipes.yoctoproject.<wbr>org</a></div><div></div><div class="m_7755332489571255702-x-evo-signature-wrapper"><span class="m_7755332489571255702-x-evo-signature" id="m_7755332489571255702none"></span></div></div></div>