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

[Khem Raj]

On 3/19/18 3:24 AM, Richard Purdie wrote:
> 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.
> 

Agreed.

> 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.

I think it could be clubbed together with a subsystem, rather than 
recipe files for better understanding. If we divide the system into set 
of meta components, e.g. kernel, toolchain, graphics, cmake based 
recipes, mason based recipes etc. then have those listed for single 
maintainer, it might work better, maybe..
maintaining build system fragments requires different skillset then 
component itself. Broadly, we need to define what abilities should be 
required of a maintainer, is it build system expertise, or component 
knowledge or both or something else.

> 
> 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.

At the very least, we will get accounting done.

> 
> 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.

This is not a big problem. There can be tooling to get whole layer view 
by parsing recipes if we agree on standard method to specify maintainers 
much like Upstream-Status in patches. That would avoid two places to 
look for information. Its also easy for new users who are learning OE. 
they get lost between config metadata and recipe metadata quite a lot. 
But its OK either way we can live with a global file maintained manually.

> 
> 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.
there has to clear SLA for maintainers to respond, a no response usually 
means maintainer is OK with the change.

> 
> 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.
> 

If accepted into layer then a revert could be a combined decision of 
layer maintainer as there are layer level integration at stake, 
maintainer and may be other stake holders. Maintainers might have better 
say when the patch is in review. However, we have overridden 
maintainers/reviewers feedback during review in past, without sufficient 
explanation, which kind of adds to confusion as to what really is 
responsibility of a recipe or sub-system 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?

This process has done well for kernel, It might slow down patch 
absorption into upstream but could improve quality of submission.

> 
> 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.

I think its not a bad idea, I see that it can help reach appropriate 
people more than what we have now. We dont always watch all the 
discussions on mailing lists, ( atleast I don't ) but if I am in CC
or To then I pay attention to 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.
> 

Yes, I stopped doing perl long time ago myself, if we have to have a 
different tool in python, is better if we can maintain it over time.

> 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.

Yes, I would think core is right place for such a change.

> 
> 
> 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
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>