[Openembedded-architecture] Recipe maintainers

[Joshua Watt]

Thanks, this is a really helpful, as both points of consideration and
history. I have a few comments:

On Mon, 2018-03-19 at 10:24 +0000, 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.

Sure, this is really part of my main drive here anyway... I'm willing
to help, but I really have no idea where help is actually needed. I can
see what layers have a "interim" maintainer, but I'm not ready to take
on maintaining a whole layer.... so where is the help actually needed?

This of course doesn't require any tooling changes... just some way of
communicating the need. I lean toward the Kernel MAINTAINERS file as
that mechanism because it can actually indicate that to me better than
simple numbers. For example, in OE-core I can easily see that developer
X maintains 100 recipes. Maybe that's OK with them, or maybe there's 30
of them they would rather not *have* to maintain and someone else can
pick them up. The MAINTAINERS format has provisions for indicating that
sort of thing.

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

I can buy that argument.... perhaps it's as simple as adding a comment:

 RECIPE_MAINTAINER_pn-foobar = "foo at bar.com" # HELP WANTED

so that I can at least get some idea of where the help is actually
needed/wanted?

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

These are all very good points... I realize that I lack the experience
here to make any arguments on them. However, I do have one valid
experience: I'm new, I want to get involved, and I'm having trouble
figuring out how/where :)

My impression is that one of the greatest current needs is to have some
"boots on the ground" to actual maintain recipes. Surely there is some
intersection of "recipes that need a (new) maintainer" and "recipes I
feel knowledgeable enough to maintain", I'm just trying to find it.

Or perhaps that isn't the most pressing need?

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

Sure, I'm really not trying to upset anyone here... I'm perfectly happy
doing nothing w.r.t. maintainer tracking infrastructure.

Thanks,
Joshua Watt

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