All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Nyström" <david.nystrom@enea.com>
To: "David Nyström" <david.nystrom@enea.com>,
	"Richard Purdie" <richard.purdie@linuxfoundation.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>,
	yocto <yocto@yoctoproject.org>
Subject: Re: Features in Yocto Project 1.7
Date: Thu, 27 Mar 2014 11:47:04 +0100	[thread overview]
Message-ID: <533401A8.60304@enea.com> (raw)
In-Reply-To: <5331935A.6060009@enea.com>

On 2014-03-25 15:31, David Nyström wrote:
> On 2014-03-24 17:00, Richard Purdie wrote:
>> As development on 1.6 finishes up, its time to think about what we
>> should be doing in the 1.7 cycle.
>>
>> I think from my perspective, in 1.7 I'd like to see us looking at
>> "Developer Workflow". Its a generic topic which I think covered multiple
>> areas (in no particular order):
>>
>> * the ADT/SDK and how it intergrates into the rest of the system
>
>> * toaster
>> * python devshell
>> * exteralsrc.bbclass
>> * memory resident bitbake
>> * how a standalone app developer might build an image
>
> +1
> My wishlist:
>
> 1. Assembly of an image from a package repository using the SDK.
> 2. Ability to easily package multiple kernel flavours(builds with
> different kernel configs) with linux related bbclass:es.

3. layer based repository splitting.
--
When having multiple users of a base repository. Ease management of 
customized repos, by having he ability to mark layers as "split layers", 
this would yield a separate repo per "split layer", which would contain 
packages modified/created by this layer.

Said packages would also be built for the base repo, but without 
split-layer modifications.

A customized distro would use a compound of the base repo + split repo, 
where the split repo would have higher priority.

I guess this could mean one deploy directory per split-layer.

Br,
David

> Br,
> David
>
>
>> * locked sstate
>>
>> and probably more I'm forgetting.
>>
>> If anyone does have things they plan to work on, or ideas for things
>> that should be worked on, please do file enhancement requests in the
>> bugzilla:
>>
>> https://bugzilla.yoctoproject.org/
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>



WARNING: multiple messages have this Message-ID (diff)
From: "David Nyström" <david.nystrom@enea.com>
To: "David Nyström" <david.nystrom@enea.com>,
	"Richard Purdie" <richard.purdie@linuxfoundation.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>,
	yocto <yocto@yoctoproject.org>
Subject: Re: [OE-core] Features in Yocto Project 1.7
Date: Thu, 27 Mar 2014 11:47:04 +0100	[thread overview]
Message-ID: <533401A8.60304@enea.com> (raw)
In-Reply-To: <5331935A.6060009@enea.com>

On 2014-03-25 15:31, David Nyström wrote:
> On 2014-03-24 17:00, Richard Purdie wrote:
>> As development on 1.6 finishes up, its time to think about what we
>> should be doing in the 1.7 cycle.
>>
>> I think from my perspective, in 1.7 I'd like to see us looking at
>> "Developer Workflow". Its a generic topic which I think covered multiple
>> areas (in no particular order):
>>
>> * the ADT/SDK and how it intergrates into the rest of the system
>
>> * toaster
>> * python devshell
>> * exteralsrc.bbclass
>> * memory resident bitbake
>> * how a standalone app developer might build an image
>
> +1
> My wishlist:
>
> 1. Assembly of an image from a package repository using the SDK.
> 2. Ability to easily package multiple kernel flavours(builds with
> different kernel configs) with linux related bbclass:es.

3. layer based repository splitting.
--
When having multiple users of a base repository. Ease management of 
customized repos, by having he ability to mark layers as "split layers", 
this would yield a separate repo per "split layer", which would contain 
packages modified/created by this layer.

Said packages would also be built for the base repo, but without 
split-layer modifications.

A customized distro would use a compound of the base repo + split repo, 
where the split repo would have higher priority.

I guess this could mean one deploy directory per split-layer.

Br,
David

> Br,
> David
>
>
>> * locked sstate
>>
>> and probably more I'm forgetting.
>>
>> If anyone does have things they plan to work on, or ideas for things
>> that should be worked on, please do file enhancement requests in the
>> bugzilla:
>>
>> https://bugzilla.yoctoproject.org/
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>



  parent reply	other threads:[~2014-03-27 10:47 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-24 16:00 Features in Yocto Project 1.7 Richard Purdie
2014-03-24 16:09 ` Jonathan Austin
2014-03-24 16:18   ` [yocto] " Richard Purdie
2014-03-24 16:18     ` Richard Purdie
2014-03-24 19:40 ` [yocto] " Rifenbark, Scott M
2014-03-24 19:40   ` Rifenbark, Scott M
2014-03-25  0:11 ` --conf Was: " Trevor Woerner
2014-03-25  0:11   ` --conf Was: [OE-core] " Trevor Woerner
2014-03-25  5:50   ` --conf Was: " Martin Jansa
2014-03-25  5:50     ` [OE-core] " Martin Jansa
2014-03-26 14:33     ` Trevor Woerner
2014-03-26 14:33       ` [OE-core] " Trevor Woerner
2014-03-26 14:38       ` Otavio Salvador
2014-03-26 14:38         ` [OE-core] " Otavio Salvador
2014-03-26 20:45         ` Nicolas Dechesne
2014-03-26 20:45           ` [OE-core] " Nicolas Dechesne
2014-03-27 16:33           ` Trevor Woerner
2014-03-27 16:33             ` [OE-core] " Trevor Woerner
2014-03-26 14:46       ` Martin Jansa
2014-03-26 14:46         ` [OE-core] " Martin Jansa
2014-03-25 12:22 ` Otavio Salvador
2014-03-25 12:22   ` [OE-core] " Otavio Salvador
2014-03-25 15:14   ` Mark Hatle
2014-03-25 14:31 ` David Nyström
2014-03-25 14:31   ` [OE-core] " David Nyström
2014-03-25 15:16   ` Mark Hatle
2014-03-25 17:37   ` [yocto] " Philip Balister
2014-03-25 17:37     ` [OE-core] " Philip Balister
2014-03-27 10:47   ` David Nyström [this message]
2014-03-27 10:47     ` David Nyström
2014-03-28 15:23     ` Otavio Salvador
2014-03-28 15:23       ` [OE-core] " Otavio Salvador
2014-03-28 18:00       ` David Nystrom
2014-03-28 18:00         ` [OE-core] " David Nystrom

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=533401A8.60304@enea.com \
    --to=david.nystrom@enea.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=yocto@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.