Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>,
	akuster808 <akuster808@gmail.com>
Cc: OpenEmbedded Devel List <openembedded-devel@lists.openembedded.org>
Subject: Re: Splitting meta-oe?
Date: Tue, 20 Feb 2018 10:52:24 -0800	[thread overview]
Message-ID: <8d5be4e4-3fd9-a0f2-c5cf-b967cf428416@gmail.com> (raw)
In-Reply-To: <CADkTA4MdQgigdN+hSsyZjk=1nfDB3M2799Pf-jy4WYt=6PdXyA@mail.gmail.com>

On 2/20/18 9:13 AM, Bruce Ashfield wrote:
> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 <akuster808@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 ?

> 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@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> 
> 
> 



  reply	other threads:[~2018-02-20 18:52 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20 10:45 Splitting meta-oe? Burton, Ross
2018-02-20 14:15 ` Joe MacDonald
2018-02-20 16:50 ` akuster808
2018-02-20 17:13   ` Bruce Ashfield
2018-02-20 18:52     ` Khem Raj [this message]
2018-02-21  0:51       ` Bruce Ashfield
2018-02-21  8:49         ` Martin Jansa
2018-02-21  9:06           ` Martin Jansa
2018-02-21  9:48             ` Andrea Adami
2018-02-21 10:22               ` Martin Jansa
2018-02-21 14:02                 ` Joe MacDonald
2018-02-21 14:14                   ` Burton, Ross
2018-02-21 14:58                     ` Patrick Ohly
2018-02-21 15:01                       ` Otavio Salvador
2018-02-21 19:33                       ` Andreas Oberritter
2018-02-22  9:18                         ` Patrick Ohly
2018-02-21 14:20                   ` Tom Rini
2018-02-21 14:44                     ` Joe MacDonald
2018-02-21 13:34           ` Bruce Ashfield
2018-02-21 13:38             ` Bruce Ashfield
2018-02-21 13:45           ` Joe MacDonald
2018-02-21 13:55             ` Bruce Ashfield
2018-02-21 13:59               ` Otavio Salvador
2018-02-20 17:46   ` Richard Purdie
2018-02-20 18:00     ` Tim Orling
2018-02-20 18:28       ` Martin Jansa
2018-02-20 18:40       ` Khem Raj
2018-02-20 18:52         ` Richard Purdie
2018-02-20 19:15           ` Khem Raj
2018-02-20 21:55             ` Richard Purdie
2018-02-20 22:27               ` Martin Jansa
2018-02-20 23:17                 ` Andreas Müller
2018-02-20 23:41                 ` Richard Purdie
2018-03-17  3:50                   ` Trevor Woerner
2018-03-17 14:23                     ` Philip Balister
2018-03-18  5:49                       ` Trevor Woerner
2018-02-21  0:07           ` Otavio Salvador
2018-02-21  0:10             ` Otavio Salvador
2018-02-21 13:57               ` Tom Rini
2018-02-21 14:00                 ` Otavio Salvador
2018-02-21 14:48                   ` Tom Rini
2018-02-21 14:09                 ` Martin Hundebøll
2018-02-22  6:53                   ` Jonas Bonn
2018-02-22  9:27                     ` Patrick Ohly
2018-02-22  9:40                       ` Otavio Salvador
2018-02-21 15:54           ` Patrick Ohly
2018-02-20 20:32         ` akuster808
2018-02-20 19:06     ` Khem Raj
2018-02-20 16:54 ` Vesa Jääskeläinen
2018-02-20 18:49 ` Khem Raj
2018-02-28 17:17 ` Alexander Kanavin
2018-02-28 21:33   ` Andreas Müller
2018-03-01  1:20     ` akuster808
2018-03-01  8:46     ` Alexander Kanavin
2018-03-01  1:17   ` akuster808
2018-03-01  9:04     ` Alexander Kanavin
2018-03-01 18:44       ` akuster808
2018-03-01 18:46         ` Alexander Kanavin
2018-03-01 22:11         ` Bruce Ashfield
  -- strict thread matches above, loose matches on Subject: below --
2017-02-17 17:07 Burton, Ross
2017-02-17 17:24 ` Andreas Müller
2017-02-17 18:02   ` Martin Jansa
2017-02-17 18:28     ` Joe MacDonald
2017-02-17 19:45       ` Philip Balister
2017-02-20  3:31         ` Richard Purdie
2017-02-20  4:28           ` Joe MacDonald
2017-02-20 11:18           ` Martin Jansa
2017-02-22 16:15             ` akuster808
2017-02-17 20:54       ` Andreas Müller
2017-02-18 21:35     ` Burton, Ross
2017-02-17 21:55 ` akuster808
2017-02-18  0:53 ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d5be4e4-3fd9-a0f2-c5cf-b967cf428416@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=akuster808@gmail.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox