On Wed, Feb 21, 2018 at 10:06 AM, Martin Jansa <[email protected]> wrote: >> 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). >
That's one point. If I may add my experience as maintainer of two minor layers (meta-handheld and meta-initramfs), I have to say there have been many cases where an upgrade to oe-core did break one of these layers. Just a variable rename for example...this fall-outs could have been avoided if the oe-core dev would have spent a minute grepping the repository, Heh..now we have to define what is the public repository, which layers have to be checked... And about layer interdependencies...well..it is very delicate. For example meta-handheld, a BSP layer, must depend since some time on meta-oe. Why? Because tslib was removed from oe-core. This is ugly...here a more separated layering structure would help So I somehow feel we should refine what is in the repository but absolutely not split it around. Even, I think we should host all public layers (definition lacks today) in the OpenEmbedded Git Repository . My 2 cents Andrea > 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 <[email protected]> > 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 <[email protected]> >> wrote: >> >>> On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj <[email protected]> wrote: >>> > On 2/20/18 9:13 AM, Bruce Ashfield wrote: >>> >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 <[email protected]> >>> 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 >>> >>> [email protected] >>> >>> 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 >>> [email protected] >>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >>> >> >> > -- > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
