[oe] Splitting meta-oe?

Wed Feb 21 09:06:07 UTC 2018

> I'm actually very worried about these (re)tired maintainers. If the
layers were more independent it would allow some of the patch handling
responsibilities and testing responsibilities to move to other people,
reducing the load on those maintainers.

Armin can update his own view, but for me the main issue wasn't the "patch
handling" part, but actually the lack of patches for the new issues (often
caused by new changes in oe-core).

Yes, the "patch handling" part was the most boring piece, but patches from
regular contributors or co-maintainers were always easy to handle and
rarely caused any extra work.

The untested drive-by contributions from people who don't even reply to
review comments are completely different category, but separate git
repositories won't drive those away (until it gets so confusing that these
people will even fail to find correct repository and just gave up trying to
contribute anything at all). Nothing is blocking more people to collect,
fix, test these drive-by contributions and then send consolidated
pull-request which will be easily merged to shared repository - but I never
seen this happen and I don't know how separate git repositories will help
with this.

In the end after spending a lot of own time doing this boring part, I
always felt responsible for fixing as many build failures detected in world
build as I could, but that's never-ending uphill battle where very few
people ever help (big thanks to those exceptions who sometimes help). And
what you get for that extra afford to get it building as much as possible
in spare time? Comments about how garbage meta-oe layers are.

We need patches not more git repos!

On Wed, Feb 21, 2018 at 9:49 AM, Martin Jansa <martin.jansa at gmail.com>
wrote:

> > I need an updated python-<foo> package for an unrelated package
>
> And how far will you go?
>
> If you want just newer python-<foo> and nothing else, will you take other
> changes to other python-* recipes from meta-python layer? There is a lot of
> recipes there, if you're so picky about updates, then you shouldn't update
> whole oe-core as well.
>
> On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield <bruce.ashfield at gmail.com>
> wrote:
>
>> On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj <raj.khem at gmail.com> wrote:
>> > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
>> >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 <akuster808 at gmail.com>
>> wrote:
>> >>>
>> >>>
>> >>> On 02/20/2018 02:45 AM, Burton, Ross wrote:
>> >>>> Hi,
>> >>>>
>> >>>> Is now a good time to talk about splitting up meta-oe?  Some layers
>> are
>> >>>> actively developed and maintained (one example: meta-python), others
>> are
>> >>>> basically bitrotting and only get touched when something else causes
>> them
>> >>>> to break world builds (one example: meta-gnome).  I've long felt that
>> >>>> meta-oe should be split up and the high quality layers managed in
>> their own
>> >>>> repositories so patches to them don't get held up by breakage in
>> other
>> >>>> sub-layers.
>> >>> You make it sound like meta-oe is not a high quality layer.  I could
>> >>> make the same claim about oe-core master.
>> >>>
>> >>> I don't see the connection in patches being held up due to breakage in
>> >>> other sub layers. This only happens if the dependency fail to build.
>> >>>
>> >>> You lose control over the quality in current layers that reside in
>> >>> meta-openbedded just like you have no control over all the other
>> layers
>> >>> residing in the community. It makes maintaining stable versions very
>> >>> difficult. Well, unless The Yocto Project takes over them.. I guess
>> that
>> >>> would work then.
>> >>>
>> >>>>
>> >>>> Another advantage of splitting out the high quality layers is that
>> we'd
>> >>>> like to look at running more community layers through the Yocto
>> >>>> autobuilder, and granular layers make that easier to manage.
>> >>>  I thought not including layers in bblayers.conf was easy enough.
>> >>>>
>> >>>> Comments?
>> >>>
>> >>> What problem do you thing you are trying to solve here?
>> >>
>> >> My unrelated issues are that I can't update one layer, without getting
>> >> all of the updates.
>> >> .. but that is both a good thing (i.e. they are all tested together,
>> >> so you know that the
>> >> single SRCREV update is good for all layers), and a bad thing (when
>> >> you just want a
>> >> new python recipe update from meta-python, but don't want other
>> changes).
>> >>
>> >
>> > if you dont include the layers in your BBLAYERS and they become
>> > effectively non existent, unless you are on metered internet connection,
>> > where downloading unused stuff would save you bandwidth, it should be
>> > ok.  No ?
>>
>> Its not that.
>>
>> I *am* building the different layers, but say I have a stable set of
>> packages
>> and working images .. but for whatever reason, I need an updated
>> python-<foo>
>> package for an unrelated package, or some other layer that needs a newer
>> version, etc.
>>
>> How do I get that, without taking updates to all the layers ? .. and
>> layers that
>> I really didn't want to update. I have to do some sort of combo-layer,
>> carry
>> my own copy of the recipe, etc.
>>
>> So there are definitely ways to do it, I'm just pointing out that I
>> end up taking
>> some build failures/issues from time to time on packages I didn't really
>> need to update.
>>
>> The flip side of that argument is that all of the layers and sub layers
>> have
>> gone through some sort of global build, and hence I know that they all
>> have
>> worked together for someone. If I can update pieces individually, I break
>> that .. and I own the broken bits after that .. which again, goes to
>> my point that
>> fixing one workflow/issue can break another :D
>>
>> Bruce
>>
>> >
>> >> It is very likely that splitting the layer would help one issue, but
>> >> make the other worse.
>> >>
>> >> So no solution from me, just an observation about potential issue.
>> >>
>> >> Cheers,
>> >>
>> >> Bruce
>> >>
>> >>>
>> >>> - armin
>> >>>>
>> >>>> Ross
>> >>>
>> >>>
>> >>> --
>> >>> _______________________________________________
>> >>> Openembedded-devel mailing list
>> >>> Openembedded-devel at lists.openembedded.org
>> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>> --
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>
>