On 02/20/2017 03:18 AM, Martin Jansa wrote:
On Sun, Feb 19, 2017 at 07:31:03PM -0800, 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.
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.
If I continue to do the same "bitbake world" builds to test as many
layers as possible, then the test time will be exactly the same even if
we split meta-oe repository into 10 smaller repositories, probably a bit
longer for fetching all those small repos.
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
I think we lack people willing to contribute patches for recipes they
use, not people willing to merge them into corresponding repository.
Correct. This does not solve the underlining issue.
We do need to think what to do about black listed recipes. Suspect its a
separate thread.
b) Having better infrastructure, tools and processes that help a) would
therefore be desirable.
Are you saying we have to make it easier for people to participate?
Please Donate to OE so we can improve the infrastructure.
If you split out each layer, each maintainer will have there own process
that works best for them.
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.
so a layer per recipe would be the best in this case. This wont bring in
more help.
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.
Yes everybody agreed that RSS is good change and worth breaking unused
recipes.
No easy answers but don't shoot Ross for asking what I think is a
reasonable question.
I wasn't trying to shoot him, but I still don't see how more
repositories solve the issue of unused recipes and lack of people
contributing to fix those still in use somewhere.
There are other implications to think about after the break-up.
1) What happens to meta-openembedded repo and or layer?
2) Do we adopt the K.O model where the sub-layers are maintained
independently and then merge to meta-openemedded ( this could offload
work and improve quality).
3) How do we sync branching? if we do #2, that is easier.
4) Since the maintainers will have write permissions for their own
layers, does this mean we no longer have overall architects (a.k.a
Martin & Koen)
5) How do we ensure the same level of support master currently benefits
from Martin's world if those responsibilities transfer to other layer
maintainers?
6) How do we enforce dup recipes?
If we decide to stop having a meta-openembedded layer;
7) How long do you keep it around?
8) Will the stable branches prior to the breakup only be in the aging
meta-openembedded layer and not new scheme?
9) Do we have a meta-openembedded-classic?
And I still think it's easier to send a patch to fix something instead
of volunteering to be maintainer of the layer with the one recipe you're
interested in fixing to merge your fix yourself.
Agree
- armin
Cheers,
--
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
