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

[Richard Purdie]

This discussion comes up now and again. I do understand why, the kernel
has a history of this and its easy to look over to what they're doing
and think we should do the same. I'd mention the following points:

a) Our real problem is having people willing to volunteer to help
maintain things. How we note that they're a maintainer isn't really a
problem, its having people willing to do it in the first place.

b) There is a question of how maintainers are assigned and accepted,
this is a challenge even in the kernel model. Who ultimately has the
say on who is accepted and who might not be or how to choose? Remember
this is a challenge for the layer maintainer with quite some potential
to upset people. We already have the issue in OE-Core, other layer
maintainers may not wish to take this on.

c) For OE-Core, it is the Yocto Project which went and drove the
creation of the list and I've made it very very clear that the YP owns
it even if we moved it from the YP layers into OE-Core. The YP
involvement was the only reason we could get coverage of everything
there. The real problem for other layers will be coverage and even if
they have a mechanism to track it, I'm not sure it will increase
coverage. I guess it would highlight where there wasn't coverage, then,
say anything not covered could be deleted. THat sounds good until you
realise people would just sign up to stop the deletion but not improve
quality. Its a tricky dilemma.

d) The single file verses recipe info is partly a maintenance problem
and partly a visibility one. One file allows you to easily see who is
overloaded and who is doing the work. Individual recipes works better
for individual users at the expense of making the bigger picture less
obvious and making block changes more of a pain.

e) Please do not underestimate the shear amount of pain that a more
fine grained mechanism will cause layer maintainers. If person X
touches a recipe maintained by person Y and person Y didn't sign off on
the change, the amount of upset that can be caused is substantial with
maintainers feeling unloved, ready to resign and so on. Without naming
names I have literally had to spend hours unravelling this kind of
problem even today for what was an accident on my part.

I do want to empower recipe maintainer, equally, the layer maintainer
needs to be empowered too. I can imagine the "X was changed but I
wasn't cc'd, I want it reverted" discussions and more and fear this
will put pressure on the layer maintainers, even if the intent is to
help them. This is perhaps the point that worries me the most. Its also
the hardest to see if you've not lived as a layer maintainer.

Am I expected to run scripts against every change to check the right
people were notified, the right people have signed off on the change
etc?

f) OE used to have a MAINTAINERS file, and MAINTAINERS recipe fields at
different points in time. Some of us who remember them, shudder at the
memories and the problems they had. I'm not sure the world has changed
enough to stop the same problems occurring unfortunately. Equally I
understand there are a lot of people who weren't there now :/.

g) There is an argument we should be able to directly use the kernel
tooling. I suspect our structure is different enough that in reality
we'd have to fork it. Last year someone tool an action to show the
kernel tooling working with OE (maybe Behan?) but nothing ever came of
it.

h) The kernel tools are also perl based iirc. My perl isn't great, our
collective skill is mainly in python and I don't want a script we can't
maintain.

i) People all see different reasons in what this tooling will do for
them, for example to get cc'd on patches to X or sign up as a
maintainer of a class/script, or have a say on patches for some regexp
of the system. We need to be really really clear on what being a
"maintainer" means and possibly does not mean. Right now we do have a
pretty specific definition for OE-Core but other layer maintainers may
or may not wish to do things differently. If things are done
differently, this will cause a new usability problem for the project.

j) Nothing is stopping other layers having maintainers files, or
maintainers listed in a file. They can decide to do that. Obviously
having good tools for such things is advantageous and if there is a a
move to this, we could share tools in core.


I do totally appreciate the motivation behind wanting to change this.
Equally there is a lot of history here, we have done some of this
before and I do worry that whilst you want to help the layer
maintainers, it may end up causing more pain.

I think for OE-Core I'm not hugely unhappy with where we are. Nothing
is there to stop other layers doing something if the maintainers want
to though...

Cheers,

Richard