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

[Joshua Watt]

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?


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
[2] http://recipes.yoctoproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20180318/692321d7/attachment-0002.html>