[oe] Splitting meta-oe?

[Joe MacDonald]

[Re: [oe] Splitting meta-oe?] On 17.02.19 (Sun 19:31) Richard Purdie wrote:

> On Fri, 2017-02-17 at 14:45 -0500, Philip Balister wrote:
> > And I'm with these gyus. Splitting the git repository doesn't solve
> > any underlying problems. The real problem from my point of view is
> > very few of use are actually paid to maintain the layers we maintain.
> > 
> > Employers want to pay things they profit from, and that is not paying
> > someone to maintain "core infrastructure".
> > 
> > Layer maintainers interests change over time, and you burn out
> > supporting people who get to do all the cool stuff with the layers
> > you maintain. In the end, you get all the crap and non of the glory.
> > Within this list, most people appreciate your work. Outside the
> > community, people completely underestimate the amount of work
> > required to keep the ecosystem running.
> > 
> > Yeah, add my name to the list of cranky people.
> 
> I do think this is a valid question that Ross asks and that whilst the
> first quick reaction is "no", its worth thinking about the pros/cons.

Absolutely, and that's why I brought up earlier that my initial proposal
for meta-networking was that it be a separate tree from the rest of
meta-oe.  When I first looked at this and what my initial goals were for
meta-networking, it made sense to me to be at arms' length.  Still does,
to be honest, but being several years into the project now I find myself
with a different mindset on the costs/benefits.

> The pros to me would be about better test time on patches and in
> theory more specialist knowledge. This isn't to say Martin/Joe don't
> do a bad job but the size of meta-oe does mean there are limits.

This is the thing that I'd like to get more of your point of view on,
because it doesn't seem clear to me.  Today, a quick survey of meta-oe
shows we have 14 top-level layers in meta-oe (yeah, does seem like a
lot) and of those I maintain one (sharing ownership with Armin when it
comes to anything netkit-related, as noted in the MAINTAINERS file) of
the others only meta-gnome seems to have only Martin listed as a
maintainer (though a few, for example gpe, multimedia and oe, have only
Martin and Koen, so there's certainly a case to be made there for there
being a larger burden on them).

Maybe we're talking specifically about meta-openembedded/meta-oe, in
which case I apologize for derailing the discussion.  I certain tried to
help that situation with creating meta-networking and moving some of the
stuff in meta-oe out into the new layer when we created it, but meta-oe
still is a really big layer (664 recipes if 'find' can be trusted), no
question.

> The cons are more around finding suitable layer maintainers, which as
> we all know are hard to find.
> 
> I'd probably suggest that:
> 
> a) We need to encourage/empower more people to maintain layers

Yes, without question.

> b) Having better infrastructure, tools and processes that help a) would
>    therefore be desirable.

The updated patchwork has seriously made my life a lot easier.  And I
don't want to go off too much on an tangent, but I'd really love to
bring meta-selinux into that same fold.

> c) We need to be willing to separate out pieces for people to maintain
>    in such layers. It might not always work out but we should be 
>    willing to try.

This is the part I'm still struggling with.  For good or ill
meta-networking got created, I've tried to maintain it reasonably
carefully and along the way the only thing that stands out for me as an
issue while remaining part of the overall meta-openembedded project was
a brief hiccup following the hardware upgrade at the end of December
where I lost the ability to push commits.  But since Martin hadn't, I
just asked him to merge the meta-networking queue I was trying to merge
and that's all sorted out now.

I certainly don't object to having another meta-something in the overall
meta-openembedded project and I don't object to having additional hands
to carry the workload, but I'm not clear how separate git repositories
addresses the current challenge.

> As for the comments about core changes, I really do try hard not to
> make them in many ways. The ones we do make, I'd hope are for the right
> reasons.
> 
> No easy answers but don't shoot Ross for asking what I think is a
> reasonable question.

I really, honestly did not mean for anything I said to sound like that.
It's good to have this kind of discussion from time to time.  It's very
easy to get stuck in the "this is the way it's always been done" rut, so
I hope Ross didn't feel like anyone was shouting him down.

Wish I was going to be around Wilsonville this week, I'd like to talk
more about this with you all.

-- 
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20170219/032c944e/attachment-0002.sig>