[Openembedded-architecture] [openembedded-architecture] Recipe maintainers

[Khem Raj]

On 3/18/18 7:12 PM, Joshua Watt wrote:
> All,
> 
> 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't sure if I should post here or openembedded-devel. 
> Someone can loop that list in if they think it is necessary.
> 
> 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.
> 
> I'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'm not necessarily proposing we have to 
> address all of them:
> 
> 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't 
> really relate to this discussion).
> 
> 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.
> 
> 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.
> 
> 
> A few possible paths forward are listed below, along with some pros and 
> cons. I'm not necessarily advocating one over the other, but just 
> listing options, please chime in with more options, or other pros/cons.
> 
> 1) Do nothing.
> Perhaps the above concerns aren't sufficiently important to warrant any 
> changes.
> 
> 2) Move the MAINTAINER variable out of maintainers.inc into each recipe.
> 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't allow for listing the maintainers of other 
> (non-recipe) files. I've heard arguments that having the maintainers 
> distributed across recipes makes them harder to maintain (e.g. they get 
> out of date), but I've also heard the argument that having them 
> centralized is harder to maintain.
> 
> 3) Switch to a Linux Kernel style MAINTAINERS file
> I've seen this one proposed in a previous discussion (can'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 other 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.
> 
> 4) Add the ability for other layers to specify their own maintainer.inc 
> files... something like a BBLAYER_MAINTAINERS variable?
> 

This is a fine idea. Instead of creating separate file, it would be best 
to maintain this information in recipe header itself, because when 
someone is working on a recipe then he/she can get all needed 
information in one place. Alpine project does it this way and Arch 
project does it too e.g. see

https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gcc

https://git.alpinelinux.org/cgit/aports/tree/main/musl/APKBUILD

see the following portion in particular.

# Maintainer:  name <email>
# Contributor: name <email>

We might make Contributor field optional or may be ignore it completely 
but we can adopt Maintainer field.


Maintaining a maintainer file is also a hassle in itself, we quite often 
patch it in OE-core too. But moving this information into recipe itself 
in a consistent way would be a good approach IMO, consist format would 
mean we can run tools over it to grok this info and also add sanity 
tests of information is missing e.g.

> 
> And now, for my personal opinion:
> 
> 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'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....
> 
> Thanks,
> Joshua Watt
> 
> [1] 
> http://lists.openembedded.org/pipermail/openembedded-architecture/2018-February/000700.html 
> <http://lists.openembedded.org/pipermail/openembedded-architecture/2018-February/000700.html>
> [2] http://recipes.yoctoproject.org <http://recipes.yoctoproject.org>
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>