Moving angstrom under the yocto banner

Moving angstrom under the yocto banner

[Koen Kooi]

Hi,

RP said I should raise this on the yocto lists, so here it is:

The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'.

What is the process to make that happen? I suspect OSVs will need to know as well, since lately yocto is being defined as 'poky + 1 bsp layer' which makes it impossible to provide any added value if you want to keep calling it 'yocto' to your customers.

regards,

Koen

Re: Moving angstrom under the yocto banner

[Osier-mixon, Jeffrey]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

As I understand it - Poky is sort of a "reference distro" for the Yocto
system. I think Angstrom would be an excellent addition as an alternative,
and I'd be happy to do anything needed on the community side to help.

On Fri, Mar 30, 2012 at 11:44 AM, Koen Kooi <koen@dominion.thruhere.net>wrote:

> Hi,
>
> RP said I should raise this on the yocto lists, so here it is:
>
> The Angstrom core team would like to move angstrom under the yocto banner
> so we can formally claim to be 'yocto'.
>
> What is the process to make that happen? I suspect OSVs will need to know
> as well, since lately yocto is being defined as 'poky + 1 bsp layer' which
> makes it impossible to provide any added value if you want to keep calling
> it 'yocto' to your customers.
>
> regards,
>
> Koen
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 1627 bytes --]

Re: Moving angstrom under the yocto banner

[Mark Hatle]

On 3/30/12 1:44 PM, Koen Kooi wrote:
> Hi,
>
> RP said I should raise this on the yocto lists, so here it is:
>
> The Angstrom core team would like to move angstrom under the yocto banner so
> we can formally claim to be 'yocto'.

For it to be on the yocto project web site, it just need to have the layers 
hosted on the git.yoctoproject.org.  But there is no "yocto".. It's the Yocto 
Project, Poky, or specific git repositories.  There is no reason we can't have 
an angstrom repository.  It could be in a similar format to the Poky repository 
(everything combined for a single download), or it could be a layer [or layers] 
that sit on top of Poky.

>
> What is the process to make that happen? I suspect OSVs will need to know as
> well, since lately yocto is being defined as 'poky + 1 bsp layer' which makes it
> impossible to provide any added value if you want to keep calling it 'yocto' to
> your customers.

I've never seen it defined as that.  I've presented on numerous occasions that 
end users using the Yocto Project build environment, Poky, should expect to add 
1 or more layers to Poky.  Usually I present that would be 2 or 3 layers 
depending on their projects.  1 (or more) BSP layers, 1 (or more) userspace 
layers, and 1 (or more) internal project/device layers.

External items come in layers and should not be modified, to ease long term 
maintenance and upgrading.  Local changes should be made in one or more layers 
depending on responsibilities, work flow and project requirements.

What I personally would like to see is Angstrom being one or more layers that 
define a new distribution that can be added to Poky (or oe-core...)

--Mark

>
> regards,
>
> Koen
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Moving angstrom under the yocto banner

[Koen Kooi]

Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:

> On 3/30/12 1:44 PM, Koen Kooi wrote:
>> Hi,
>> 
>> RP said I should raise this on the yocto lists, so here it is:
>> 
>> The Angstrom core team would like to move angstrom under the yocto banner so
>> we can formally claim to be 'yocto'.
> 
> For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org.  But there is no "yocto".. It's the Yocto Project, Poky, or specific git repositories.  There is no reason we can't have an angstrom repository.  It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky.

Why on top of poky? I do not want poky, nor do my customers, oe-core is what we need and want. This proposal to move angstrom under yocto is targeted at eliminating 'poky' from the stack while still being able to say 'yocto'.

We both know that saying it is 'yocto' is wrong and misleading, but that's what users are asking for and yocto advocates seem to push. Just watch the ELC videos for yocto related presentations, 'yocto' and 'poky' are used interchangeably in most of them.

A 'reference' should be just that, a reference, not a mandated part. 

regards,

Koen

Re: Moving angstrom under the yocto banner

[Mark Hatle]

On 3/30/12 2:33 PM, Koen Kooi wrote:
>
> Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
>
>> On 3/30/12 1:44 PM, Koen Kooi wrote:
>>> Hi,
>>>
>>> RP said I should raise this on the yocto lists, so here it is:
>>>
>>> The Angstrom core team would like to move angstrom under the yocto banner so
>>> we can formally claim to be 'yocto'.
>>
>> For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org.  But there is no "yocto".. It's the Yocto Project, Poky, or specific git repositories.  There is no reason we can't have an angstrom repository.  It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky.
>
> Why on top of poky? I do not want poky, nor do my customers, oe-core is what
> we need and want. This proposal to move angstrom under yocto is targeted at
> eliminating 'poky' from the stack while still being able to say 'yocto'.

Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a 
distribution definition (in meta-yocto).  I assume angstrom has it's own 
distribution definition.

So my question is why NOT on top of Poky (the repository, not distribution 
definition)?

>
> We both know that saying it is 'yocto' is wrong and misleading, but that's
> what users are asking for and yocto advocates seem to push. Just watch the ELC
> videos for yocto related presentations, 'yocto' and 'poky' are used
> interchangeably in most of them.
>
> A 'reference' should be just that, a reference, not a mandated part.

It's hard to call something Yocto Project based unless it used something from 
the Yocto Project.  meta-yocto being on of those components.

There is enough confusion about yocto vs poky vs..  It's slowly being reconciled 
and defined.. but it's a slow process for all of us.

--Mark

>
> regards,
>
> Koen

Re: Moving angstrom under the yocto banner

[Koen Kooi]

Op 30 mrt. 2012, om 13:18 heeft Mark Hatle het volgende geschreven:

> On 3/30/12 2:33 PM, Koen Kooi wrote:
>> 
>> Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
>> 
>>> On 3/30/12 1:44 PM, Koen Kooi wrote:
>>>> Hi,
>>>> 
>>>> RP said I should raise this on the yocto lists, so here it is:
>>>> 
>>>> The Angstrom core team would like to move angstrom under the yocto banner so
>>>> we can formally claim to be 'yocto'.
>>> 
>>> For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org.  But there is no "yocto".. It's the Yocto Project, Poky, or specific git repositories.  There is no reason we can't have an angstrom repository.  It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky.
>> 
>> Why on top of poky? I do not want poky, nor do my customers, oe-core is what
>> we need and want. This proposal to move angstrom under yocto is targeted at
>> eliminating 'poky' from the stack while still being able to say 'yocto'.
> 
> Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a distribution definition (in meta-yocto).  I assume angstrom has it's own distribution definition.
> 
> So my question is why NOT on top of Poky (the repository, not distribution definition)?

1) It's downstream, I want to use upstream (oe-core, bitbake)
2) meta-yocto is *absolutely* unwanted, the meta-ti layer angstrom uses has much, much better support for the beagleboard.
3) It's downstream
4) The combo repo makes it harder to contribute things back upstream
5) It's downstream

I know I can change bblayers.conf to remove any unwanted layers, but what's the point of using that combo repo if I do that? It means that angstrom developers have to spend more time explaining that yes, it's a single git repo, but no, you can't send patches against it.

>> We both know that saying it is 'yocto' is wrong and misleading, but that's
>> what users are asking for and yocto advocates seem to push. Just watch the ELC
>> videos for yocto related presentations, 'yocto' and 'poky' are used
>> interchangeably in most of them.
>> 
>> A 'reference' should be just that, a reference, not a mandated part.
> 
> It's hard to call something Yocto Project based unless it used something from the Yocto Project.  meta-yocto being on of those components.

So you are saying that meta-yocto is an absolute requirement for anything that wants to use 'yocto' in its messaging?

> There is enough confusion about yocto vs poky vs..  It's slowly being reconciled and defined.. but it's a slow process for all of us.

Hence this proposal.

Re: Moving angstrom under the yocto banner

[Tom Rini]

On Fri, Mar 30, 2012 at 03:18:06PM -0500, Mark Hatle wrote:
> On 3/30/12 2:33 PM, Koen Kooi wrote:
> >
> >Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
> >
> >>On 3/30/12 1:44 PM, Koen Kooi wrote:
> >>>Hi,
> >>>
> >>>RP said I should raise this on the yocto lists, so here it is:
> >>>
> >>>The Angstrom core team would like to move angstrom under the yocto banner so
> >>>we can formally claim to be 'yocto'.
> >>
> >>For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org.  But there is no "yocto".. It's the Yocto Project, Poky, or specific git repositories.  There is no reason we can't have an angstrom repository.  It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky.
> >
> >Why on top of poky? I do not want poky, nor do my customers, oe-core is what
> >we need and want. This proposal to move angstrom under yocto is targeted at
> >eliminating 'poky' from the stack while still being able to say 'yocto'.
> 
> Poky is a repository made up of bitbake + oe-core + meta-yocto, as
> well as a distribution definition (in meta-yocto).  I assume
> angstrom has it's own distribution definition.
> 
> So my question is why NOT on top of Poky (the repository, not
> distribution definition)?

What does being on top of poky buy the end user?  ${some_tool} will be
grabbing the repositories so it's not easier to grab bitbake + oe-core
as one.  It adds a barrier to end user to developer conversion since
we'll have a lot of "OK, thanks for your contribution but next time
please base against oe-core directly not poky".  Not to speak for Denys
or Chase but for Arago, why would we want to have the poky sample distro
around on top of our distro?

> >We both know that saying it is 'yocto' is wrong and misleading, but that's
> >what users are asking for and yocto advocates seem to push. Just watch the ELC
> >videos for yocto related presentations, 'yocto' and 'poky' are used
> >interchangeably in most of them.
> >
> >A 'reference' should be just that, a reference, not a mandated part.
> 
> It's hard to call something Yocto Project based unless it used
> something from the Yocto Project.  meta-yocto being on of those
> components.

So bitbake and oe-core don't count because they're external projects?

> There is enough confusion about yocto vs poky vs..  It's slowly
> being reconciled and defined.. but it's a slow process for all of
> us.

Right.  But we should probably reiterate that one of the goals was to be
able to say that components X/Y/Z make up a release.  And while a merged
repo makes sense in terms of a reference platform (and since git
submodules, repo, etc, etc, each have their own problems) it wasn't the
intent to say you must use this merged repo.

-- 
Tom

Re: Moving angstrom under the yocto banner

[Koen Kooi]

Op 30 mrt. 2012, om 13:45 heeft Tom Rini het volgende geschreven:

> On Fri, Mar 30, 2012 at 03:18:06PM -0500, Mark Hatle wrote:
>> On 3/30/12 2:33 PM, Koen Kooi wrote:
>>> 
>>> Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
>>> 
>>>> On 3/30/12 1:44 PM, Koen Kooi wrote:
>>>>> Hi,
>>>>> 
>>>>> RP said I should raise this on the yocto lists, so here it is:
>>>>> 
>>>>> The Angstrom core team would like to move angstrom under the yocto banner so
>>>>> we can formally claim to be 'yocto'.
>>>> 
>>>> For it to be on the yocto project web site, it just need to have the layers hosted on the git.yoctoproject.org.  But there is no "yocto".. It's the Yocto Project, Poky, or specific git repositories.  There is no reason we can't have an angstrom repository.  It could be in a similar format to the Poky repository (everything combined for a single download), or it could be a layer [or layers] that sit on top of Poky.
>>> 
>>> Why on top of poky? I do not want poky, nor do my customers, oe-core is what
>>> we need and want. This proposal to move angstrom under yocto is targeted at
>>> eliminating 'poky' from the stack while still being able to say 'yocto'.
>> 
>> Poky is a repository made up of bitbake + oe-core + meta-yocto, as
>> well as a distribution definition (in meta-yocto).  I assume
>> angstrom has it's own distribution definition.
>> 
>> So my question is why NOT on top of Poky (the repository, not
>> distribution definition)?
> 
> What does being on top of poky buy the end user?  ${some_tool} will be
> grabbing the repositories so it's not easier to grab bitbake + oe-core
> as one.  It adds a barrier to end user to developer conversion since
> we'll have a lot of "OK, thanks for your contribution but next time
> please base against oe-core directly not poky".  Not to speak for Denys
> or Chase but for Arago, why would we want to have the poky sample distro
> around on top of our distro?
> 
>>> We both know that saying it is 'yocto' is wrong and misleading, but that's
>>> what users are asking for and yocto advocates seem to push. Just watch the ELC
>>> videos for yocto related presentations, 'yocto' and 'poky' are used
>>> interchangeably in most of them.
>>> 
>>> A 'reference' should be just that, a reference, not a mandated part.
>> 
>> It's hard to call something Yocto Project based unless it used
>> something from the Yocto Project.  meta-yocto being on of those
>> components.
> 
> So bitbake and oe-core don't count because they're external projects?

If oe-core doesn't count, that will go directly against the agreement the OE developers made with the yocto ones when deciding to drop OE classic and start oe-core.
If that's really the position of the yocto project I think the OE project will need to seriously reconsider the merge and its participation in the yocto project.

regards,

Koen

Re: Moving angstrom under the yocto banner

[Osier-mixon, Jeffrey]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

>
> >> It's hard to call something Yocto Project based unless it used
> >> something from the Yocto Project.  meta-yocto being on of those
> >> components.
> >
> > So bitbake and oe-core don't count because they're external projects?
>
> If oe-core doesn't count, that will go directly against the agreement the
> OE developers made with the yocto ones when deciding to drop OE classic and
> start oe-core.
> If that's really the position of the yocto project I think the OE project
> will need to seriously reconsider the merge and its participation in the
> yocto project.
>

Mark said above: "It's hard to call something YP based unless it uses
something from the Yocto Project". meta-yocto is one example, but so is
oe-core.

oe-core is shared code between Yocto and OE. Thus, it is reasonable to say
that any distribution that uses oe-core is representative of the Yocto
Project, to some degree. So of course oe-core counts, as does bitbake,
another shared component.



>
> regards,
>
> Koen
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 2053 bytes --]

Re: Moving angstrom under the yocto banner

[Osier-mixon, Jeffrey]

[-- Attachment #1: Type: text/plain, Size: 6639 bytes --]

I have some hope of bringing a little bit of order to the chaos that seems
to be ensuing here. I am speaking here from my own understanding, which may
or may not be correct.

On Fri, Mar 30, 2012 at 1:18 PM, Mark Hatle <mark.hatle@windriver.com>wrote:

> On 3/30/12 2:33 PM, Koen Kooi wrote:
>
>>
>> Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
>>
>>  On 3/30/12 1:44 PM, Koen Kooi wrote:
>>>
>>>> Hi,
>>>>
>>>> RP said I should raise this on the yocto lists, so here it is:
>>>>
>>>> The Angstrom core team would like to move angstrom under the yocto
>>>> banner so
>>>> we can formally claim to be 'yocto'.
>>>>
>>>
>>> For it to be on the yocto project web site, it just need to have the
>>> layers hosted on the git.yoctoproject.org.  But there is no "yocto"..
>>> It's the Yocto Project, Poky, or specific git repositories.  There is no
>>> reason we can't have an angstrom repository.  It could be in a similar
>>> format to the Poky repository (everything combined for a single download),
>>> or it could be a layer [or layers] that sit on top of Poky.
>>>
>>
>> Why on top of poky? I do not want poky, nor do my customers, oe-core is
>> what
>> we need and want. This proposal to move angstrom under yocto is targeted
>> at
>> eliminating 'poky' from the stack while still being able to say 'yocto'.
>>
>
> Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as
> a distribution definition (in meta-yocto).  I assume angstrom has it's own
> distribution definition.
>
> So my question is why NOT on top of Poky (the repository, not distribution
> definition)?


I think I understand what Koen is after - an alternative reference
distribution for the Yocto Project. I think this issue provides us with the
opportunity to really nail down what is, and what isn't, the Yocto Project.
(Since this discussion is happening on the yocto mailing list.)

I see it as:
- a build took (BitBake), whose maintenance is shared with OE
- a set of metadata:
  some maintained under the Yocto Project banner (e.g. meta-yocto &
linux-yocto)
  some shared with others (oe-core)
  some outside but hosted on yp.org
- several build-related tools utilities (e.g. swabber, ADT, etc)
- embedded related libraries (e.g. EGLIBC)

What these all have in common is that they are related to embedded Linux
development, they are maintained under the Yocto Project banner, and they
are all tested together in the course of our release process.

I think most of the confusion among Yocto, Poky, and OE comes from legacy
descriptions. At one time, Poky was itself a build "system", and the
various layers were not separate projects. It was similar to OE classic.
Now functionality all lives in separate layers, most of them
interchangeable between Yocto and OE.

Definition-wise, we need to remember that the Yocto Project is a *project*,
not a distribution, and not a consortium. It isn't a sticker one could put
on a box to say "yocto inside". As the project website says, it
provides templates,
tools and methods to help you create custom Linux-based systems. It is not
a distribution itself, but it does have a reference system called Poky that
is working, tested representation of all of these things together.

Thus, there is no "yocto distribution". I think it would be correct to say
that any release that uses the linux-yocto and/or meta-yocto layer would be
representative of the Yocto Project. If a distro uses BitBake, oe-core, and
a BSP maintained or obtained from a Yocto Project repository, that's a grey
area. If a distro uses nothing maintained on yoctoproject.org, I would
suggest that it is not representative of the Yocto Project, although it may
be compatible with it.

BitBake and oe-core are shared components between Yocto and OE, so by this
circuitous definition, Angstrom could be considered representative of the
Yocto Project to some extent, as it uses Yocto Project components as its
upstream. Poky does as well, but Poky uses only Yocto-maintained components
(I think?) and represents all of the various components of the build system
working together, and it is tested as such.

Does that mean that Poky is more representative of the Yocto Project than
Angstrom? Possibly so. But it does not mean Angstrom is unrepresentative.
Angstrom uses some Yocto-maintained components and some that are not
maintained by the Yocto Project, just as Ubuntu uses some Debian components
and some that are not maintained or supported by Debian.


>
>> We both know that saying it is 'yocto' is wrong and misleading, but that's
>> what users are asking for and yocto advocates seem to push. Just watch
>> the ELC
>> videos for yocto related presentations, 'yocto' and 'poky' are used
>> interchangeably in most of them.
>>
>> A 'reference' should be just that, a reference, not a mandated part.
>>
>
> It's hard to call something Yocto Project based unless it used something
> from the Yocto Project.  meta-yocto being on of those components.
>
> There is enough confusion about yocto vs poky vs..  It's slowly being
> reconciled and defined.. but it's a slow process for all of us.


Angstrom does use oe-core, but I don't think it uses linux-yocto (right?)
and definitely not meta-yocto. In fact, I don't think it depends on any
components that are solely maintained under the Yocto Project banner. It
does depend on two components with shared responsibility between Yocto and
OE, namely oe-core and bitbake.

That does not stop it from being represented under the Yocto Project if
that is the maintainer's wish and if that representation is amenable to the
project's technical maintainers and the Advisory Board. If the goal is to
avoid future misunderstandings, however, this may not be the best way to do
it. I think community education may be the best way to address that
problem, and in order to do that, everyone involved needs to understand and
agree on the definitions. As Mark says, we are getting there, slowly.

My feeling is that if Koen wants Angstrom to be represented under the Yocto
Project banner, it can do so if the Yocto Project maintainers agree to do
it. If Koen wants Angstrom to be considered representative of the Yocto
Project, it can do so to the extent that it is based on the components it
uses that are maintained (fully or partially) by projects under the Yocto
Project.

Again, someone please let me know if I am mistaken.

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 8406 bytes --]

Re: Moving angstrom under the yocto banner

[Eric Bénard]

Le Fri, 30 Mar 2012 13:45:16 -0700,
Tom Rini <tom.rini@gmail.com> a écrit :
> > It's hard to call something Yocto Project based unless it used
> > something from the Yocto Project.  meta-yocto being on of those
> > components.
> 
> So bitbake and oe-core don't count because they're external projects?
> 
on the technical point of view
http://git.yoctoproject.org/cgit/cgit.cgi/poky/
~=
http://cgit.openembedded.org/openembedded-core/
+
http://cgit.openembedded.org/bitbake/
+
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto

so I think it's hard to say bitbake & oe-core don't count !

On a non technical point of view, IANAL but "Yocto Project" being a
Linux Fundation trademark, that's not the inclusion of meta-yocto which
says how to use the name but this page :
http://www.linuxfoundation.org/about/linux-foundation-trademark-usage-guidelines

Eric

Re: Moving angstrom under the yocto banner

[Richard Purdie]

On Fri, 2012-03-30 at 15:18 -0500, Mark Hatle wrote:
> On 3/30/12 2:33 PM, Koen Kooi wrote:
> >
> > Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
> >
> >> On 3/30/12 1:44 PM, Koen Kooi wrote:
> >>> Hi,
> >>>
> >>> RP said I should raise this on the yocto lists, so here it is:
> >>>
> >>> The Angstrom core team would like to move angstrom under the yocto banner so
> >>> we can formally claim to be 'yocto'.

In the interests of clarity, as Tracey will tell you there is no
"Yocto" (which is an SI prefix), only the "Yocto Project" :). I know
some of us have bad habits but since we're trying to ensure we're all
consistent, this is worth highlighting.

> >> For it to be on the yocto project web site, it just need to have
> the layers hosted on the git.yoctoproject.org.  But there is no
> "yocto".. It's the Yocto Project, Poky, or specific git repositories.
> There is no reason we can't have an angstrom repository.  It could be
> in a similar format to the Poky repository (everything combined for a
> single download), or it could be a layer [or layers] that sit on top
> of Poky.
> >
> > Why on top of poky? I do not want poky, nor do my customers, oe-core is what
> > we need and want. This proposal to move angstrom under yocto is targeted at
> > eliminating 'poky' from the stack while still being able to say 'yocto'.
> 
> Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a 
> distribution definition (in meta-yocto).  I assume angstrom has it's own 
> distribution definition.
> 
> So my question is why NOT on top of Poky (the repository, not distribution 
> definition)?

FWIW I don't think it has to be "on top of Poky". 

Basically the question is whether you'd include the meta-yocto layer or
not. I know that doesn't have its own repository yet (but that's purely
a time thing). I have no strong feelings either way about the inclusion
of that layer. Its purposefully not got that much in it (one distro
definition and some hardware/BSP addons).

Also, Angstrom has a different repository format in the way the user
fetches and interacts with layers. I don't think Yocto mandates any
requirement in that area, or that it needs to.

> > We both know that saying it is 'yocto' is wrong and misleading, but that's
> > what users are asking for and yocto advocates seem to push.

Try saying this in earshot of Tracey ;-). We are trying to do a better
job of saying "Yocto Project", please help us!

>  Just watch the ELC
> > videos for yocto related presentations, 'yocto' and 'poky' are used
> > interchangeably in most of them.
> >
> > A 'reference' should be just that, a reference, not a mandated part.
> 
> It's hard to call something Yocto Project based unless it used something from 
> the Yocto Project.  meta-yocto being on of those components.

The criteria I see for being part of the Yocto Project are:

a) Sharing the project's objectives (e.g. making embedded Liunx 
   development easier)
b) Willing to be part of the Yocto Project's governance structure
c) Bringing something new/beneficial to the Yocto Project (often with 
   mutual benefit)
d) Have some kind of sustainable resource plan

Note that it I don't list "must use meta-yocto" there since I don't
think that is true.

I would want to be clear about where I'd see Angstrom positioned within
the Yocto Project which would be as a reference binary distribution.

This is in contrast with Poky which would remain as the getting started
and reference testing configuration (obviously building from
source/sstate in contrast to Angstrom).

I do have some questions related to some of the above points but I'm
going to hold off those for now and see where this discussion goes. I'd
also mention that I'd like to see what advice the advisory board has on
this topic too.

> There is enough confusion about yocto vs poky vs..  It's slowly being reconciled 
> and defined.. but it's a slow process for all of us.

Right, I think we are getting to grips with this slowly and there was a
good discussion about this on the meta-ti list recently.

Cheers,

Richard

Re: Moving angstrom under the yocto banner

[Koen Kooi]

My apologies for loosing the reply indent, I blame apple mail

Op 30 mrt. 2012, om 14:01 heeft Osier-mixon, Jeffrey het volgende geschreven:
> 
> Angstrom does use oe-core, but I don't think it uses linux-yocto (right?) and definitely not meta-yocto. 

linux-yocto is a kernel, which is used by machines in meta-intel, which angstrom supports (only fri2 atm), so the choice to use or not use linux-yocto is up to th e BSP, not to angstrom. OE was founded on the principle that machines, images and distros are orthogonal. Angstrom does cheat a bit with images, but it is *not* changing any machine definitions.

This is what angstrom is currently using:

[koen@Angstrom-F16-vm-rpm setup-scripts]$ cat sources/layers.txt 
# Name,repo-uri,branch,rev
bitbake,git://github.com/openembedded/bitbake.git,master,HEAD
meta-angstrom,git://github.com/Angstrom-distribution/meta-angstrom,master,HEAD
meta-openembedded,git://github.com/openembedded/meta-oe.git,master,HEAD
meta-ti,git://git.yoctoproject.org/meta-ti,master,HEAD
meta-ettus,git://github.com/balister/meta-ettus.git,master,HEAD
meta-efikamx,git://github.com/kraj/meta-efikamx.git,master,HEAD
meta-nslu2,git://github.com/kraj/meta-nslu2.git,master,HEAD
meta-smartphone,http://git.shr-project.org/repo/meta-smartphone.git,master,HEAD
meta-intel,git://git.yoctoproject.org/meta-intel,master,HEAD
meta-xilinx,git://git.yoctoproject.org/meta-xilinx,master,HEAD
meta-openpandora,git://github.com/openpandora/meta-openpandora.git,master,HEAD
meta-handheld,git://git.openembedded.org/meta-handheld,master,HEAD
meta-opie,git://github.com/bluelightning/meta-opie.git,master,HEAD
meta-java,git://github.com/woglinde/meta-java.git,master,HEAD
meta-mozilla,git://github.com/OSSystems/meta-mozilla.git,master,HEAD
meta-mono,git://github.com/KokoFitClub/meta-mono.git,master,HEAD
openembedded-core,git://github.com/openembedded/oe-core.git,master,HEAD

It will add more bsp layers soon (fsl-ppc, fsl-arm, etc) before the release.

And the layer config:

[koen@Angstrom-F16-vm-rpm setup-scripts]$ cat conf/bblayers.conf 
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
TOPDIR := "${@os.path.dirname(os.path.dirname(d.getVar('FILE', True)))}"

BBPATH = "${TOPDIR}"

BBFILES = ""

# These layers hold recipe metadata not found in OE-core, but lack any machine or distro content
BASELAYERS ?= " \
  ${TOPDIR}/sources/meta-openembedded/meta-oe \
  ${TOPDIR}/sources/meta-openembedded/toolchain-layer \
  ${TOPDIR}/sources/meta-openembedded/meta-efl \
  ${TOPDIR}/sources/meta-openembedded/meta-gpe \
  ${TOPDIR}/sources/meta-openembedded/meta-gnome \
  ${TOPDIR}/sources/meta-openembedded/meta-xfce \
  ${TOPDIR}/sources/meta-openembedded/meta-initramfs \
  ${TOPDIR}/sources/meta-opie \
  ${TOPDIR}/sources/meta-java \
  ${TOPDIR}/sources/meta-mozilla \
"

# These layers hold machine specific content, aka Board Support Packages
BSPLAYERS ?= " \
  ${TOPDIR}/sources/meta-ti \
  ${TOPDIR}/sources/meta-efikamx \
  ${TOPDIR}/sources/meta-nslu2 \
  ${TOPDIR}/sources/meta-smartphone/meta-htc \
  ${TOPDIR}/sources/meta-smartphone/meta-nokia \
  ${TOPDIR}/sources/meta-smartphone/meta-openmoko \
  ${TOPDIR}/sources/meta-smartphone/meta-palm \
  ${TOPDIR}/sources/meta-handheld \
  ${TOPDIR}/sources/meta-intel \
  ${TOPDIR}/sources/meta-intel/meta-sugarbay \
  ${TOPDIR}/sources/meta-intel/meta-crownbay \
  ${TOPDIR}/sources/meta-intel/meta-emenlow \
  ${TOPDIR}/sources/meta-intel/meta-fishriver \
  ${TOPDIR}/sources/meta-intel/meta-jasperforest \
  ${TOPDIR}/sources/meta-intel/meta-n450 \
"

# Add your overlay location to EXTRALAYERS
# Make sure to have a conf/layers.conf in there
EXTRALAYERS ?= ""

BBLAYERS = " \
  ${TOPDIR}/sources/meta-angstrom \
  ${BASELAYERS} \
  ${BSPLAYERS} \
  ${EXTRALAYERS} \
  ${TOPDIR}/sources/openembedded-core/meta \
  "

regards,

Koen

Re: Moving angstrom under the yocto banner

[Stewart, David C]

>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of Richard Purdie
>Sent: Friday, March 30, 2012 2:11 PM
>
>The criteria I see for being part of the Yocto Project are:
>
>a) Sharing the project's objectives (e.g. making embedded Liunx
>   development easier)
>b) Willing to be part of the Yocto Project's governance structure
>c) Bringing something new/beneficial to the Yocto Project (often with
>   mutual benefit)
>d) Have some kind of sustainable resource plan

I would add:
e) there should be interoperability with the other parts of the YP.

Part of the benefit we're trying to create is that if someone invests in YP 
for their device, they should get benefit from the whole thing.  If a board
manufacturer creates a BSP for YP v1.2, there should be no doubt whatsoever
that it will work with that system.  Can anyone assure me that such a BSP
would work under Angstrom?

Or I develop a layer for an app on Angstrom. Do I know for sure that it will for 
sure work on MEL, which has YP as its upstream?

See where I'm going with this?

Finally, Dr. Kooi has stated that he doesn't see YP as an upstream. In fact, many 
of the OSVs (like Wind River, Mentor Graphics and now ENEA - yeah!) absolutely
want to use YP as their upstream. So I'm hoping we could change the definition
of YP/Poky/Angstrom so Angstrom could us Poky as its upstream ... no? Too
hard?

Anyway, if we can't get to this level of interoperability, then adding Angstrom 
to the Yocto project may add too much confusion.

Dave

Re: Moving angstrom under the yocto banner

[Chris Larson]

On Fri, Mar 30, 2012 at 4:06 PM, Stewart, David C
<david.c.stewart@intel.com> wrote:
>>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>>bounces@yoctoproject.org] On Behalf Of Richard Purdie
>>Sent: Friday, March 30, 2012 2:11 PM
>>
>>The criteria I see for being part of the Yocto Project are:
>>
>>a) Sharing the project's objectives (e.g. making embedded Liunx
>>   development easier)
>>b) Willing to be part of the Yocto Project's governance structure
>>c) Bringing something new/beneficial to the Yocto Project (often with
>>   mutual benefit)
>>d) Have some kind of sustainable resource plan
>
> I would add:
> e) there should be interoperability with the other parts of the YP.
>
> Part of the benefit we're trying to create is that if someone invests in YP
> for their device, they should get benefit from the whole thing.  If a board
> manufacturer creates a BSP for YP v1.2, there should be no doubt whatsoever
> that it will work with that system.  Can anyone assure me that such a BSP
> would work under Angstrom?

Given that an OE priority has *always* been that distro, machine, and
image are largely independent, orthogonal components, and generally
speaking one can combine any combination of the three and have at
least a good shot at functionality, I'd say that if such a BSP did not
work under Angstrom, that'd be a bug that we'd all agree would need to
be fixed. As far as I know, this priority and attribute of the system
still exists.
-- 
Christopher Larson

Re: Moving angstrom under the yocto banner

[Tom Rini]

On Fri, Mar 30, 2012 at 04:09:37PM -0700, Chris Larson wrote:
> On Fri, Mar 30, 2012 at 4:06 PM, Stewart, David C
> <david.c.stewart@intel.com> wrote:
> >>From: yocto-bounces@yoctoproject.org [mailto:yocto-
> >>bounces@yoctoproject.org] On Behalf Of Richard Purdie
> >>Sent: Friday, March 30, 2012 2:11 PM
> >>
> >>The criteria I see for being part of the Yocto Project are:
> >>
> >>a) Sharing the project's objectives (e.g. making embedded Liunx
> >> ?? development easier)
> >>b) Willing to be part of the Yocto Project's governance structure
> >>c) Bringing something new/beneficial to the Yocto Project (often with
> >> ?? mutual benefit)
> >>d) Have some kind of sustainable resource plan
> >
> > I would add:
> > e) there should be interoperability with the other parts of the YP.
> >
> > Part of the benefit we're trying to create is that if someone invests in YP
> > for their device, they should get benefit from the whole thing. ??If a board
> > manufacturer creates a BSP for YP v1.2, there should be no doubt whatsoever
> > that it will work with that system. ??Can anyone assure me that such a BSP
> > would work under Angstrom?
> 
> Given that an OE priority has *always* been that distro, machine, and
> image are largely independent, orthogonal components, and generally
> speaking one can combine any combination of the three and have at
> least a good shot at functionality, I'd say that if such a BSP did not
> work under Angstrom, that'd be a bug that we'd all agree would need to
> be fixed. As far as I know, this priority and attribute of the system
> still exists.

This is also my understanding and expectation.

-- 
Tom

Re: Moving angstrom under the yocto banner

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

On Fri, Mar 30, 2012 at 11:06:04PM +0000, Stewart, David C wrote:

> Finally, Dr. Kooi has stated that he doesn't see YP as an upstream. In fact, many 
> of the OSVs (like Wind River, Mentor Graphics and now ENEA - yeah!) absolutely
> want to use YP as their upstream. So I'm hoping we could change the definition
> of YP/Poky/Angstrom so Angstrom could us Poky as its upstream ... no? Too
> hard?

Putting on my "me, myself and I" hat and apologizing for putting words
in a few peoples mouths, I think this speaks to the heart of the problem
Koen is trying to express.  On a technical level, the goal has been
something (and I'm simplifying a bit here) to say that poky (the distro)
is an implementation of policy for oe-core.  oe-core, bitbake and N
number of other layers (meta-intel, meta-fsl-ppc, meta-ti, meta-java,
meta-oe, meta-so-on-and-so-forth) will say that this is their metadata
for release X.  Some of these layers (bitbake, oe-core, poky the distro)
are maintained by 'Yocto Project' folks like Richard.  Others are
maintained by community folks (Koen, Eric B.) or other companies
(Denys).

Now, you say "YP is an upstream".  But "Yocto Project" is an upstream
for bitbake, and for openembedded-core and for poky (the distro) and a
lot of other stuff.  However, meta-yocto (what got us going in this
direction) is only an upstream for poky (the distro), and Richard has
said it's a TODO list item to move poky (the distro) into a separate
repository and thus make meta-yocto ONLY a conglomeration of other
repositories.

It's GOOD that companies want to work with upstream, and at some high
level "Yocto Project" is where that is, in so far as bitbake,
openembedded-core, etc, get a lot of time and energy and resources of
"Yocto Project" people.  But these also get community resources too.
Koen for example DOES see "Yocto Project" as an upstream in that he
contributes to openembedded-core, etc, etc.  Angstrom also sees "Yocto
Project" as an upstream for the same reasons.  But on a technical level,
none of us would say it that way.

And this is where the confusion emanates from I believe.  You're saying
that Angstrom (the distro) should see poky (the distro) as it's
upstream.  If I was a runner, I could make an analogy you would say "but
that's silly!" and I would say "exactly!" and we'd all be on the same
page.  So can we pretend I did?

> Anyway, if we can't get to this level of interoperability, then adding Angstrom 
> to the Yocto project may add too much confusion.

If someone makes a layer and it works with meta-yocto +
meta-SomeHWVendor and fails with meta-angstrom + openembedded-core +
bitbake + meta-SomeHWVendor (and you can replace meta-angstrom with
meta-arago or any other layer that provides distro policy) it's a bug,
not a feature, and not what anyone expects to happen today.

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Moving angstrom under the yocto banner

[Darren Hart]

On 03/30/2012 02:11 PM, Richard Purdie wrote:
> On Fri, 2012-03-30 at 15:18 -0500, Mark Hatle wrote:
>> On 3/30/12 2:33 PM, Koen Kooi wrote:
>>>
>>> Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
>>>
>>>> On 3/30/12 1:44 PM, Koen Kooi wrote:
>>>>> Hi,
>>>>>
>>>>> RP said I should raise this on the yocto lists, so here it is:
>>>>>
>>>>> The Angstrom core team would like to move angstrom under the yocto banner so
>>>>> we can formally claim to be 'yocto'.
> 
> In the interests of clarity, as Tracey will tell you there is no
> "Yocto" (which is an SI prefix), only the "Yocto Project" :). I know
> some of us have bad habits but since we're trying to ensure we're all
> consistent, this is worth highlighting.
> 
>>>> For it to be on the yocto project web site, it just need to have
>> the layers hosted on the git.yoctoproject.org.  But there is no
>> "yocto".. It's the Yocto Project, Poky, or specific git repositories.
>> There is no reason we can't have an angstrom repository.  It could be
>> in a similar format to the Poky repository (everything combined for a
>> single download), or it could be a layer [or layers] that sit on top
>> of Poky.
>>>
>>> Why on top of poky? I do not want poky, nor do my customers, oe-core is what
>>> we need and want. This proposal to move angstrom under yocto is targeted at
>>> eliminating 'poky' from the stack while still being able to say 'yocto'.
>>
>> Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a 
>> distribution definition (in meta-yocto).  I assume angstrom has it's own 
>> distribution definition.
>>
>> So my question is why NOT on top of Poky (the repository, not distribution 
>> definition)?
> 
> FWIW I don't think it has to be "on top of Poky". 
> 
> Basically the question is whether you'd include the meta-yocto layer or
> not. I know that doesn't have its own repository yet (but that's purely
> a time thing). I have no strong feelings either way about the inclusion
> of that layer. Its purposefully not got that much in it (one distro
> definition and some hardware/BSP addons).
> 
> Also, Angstrom has a different repository format in the way the user
> fetches and interacts with layers. I don't think Yocto mandates any
> requirement in that area, or that it needs to.
> 
>>> We both know that saying it is 'yocto' is wrong and misleading, but that's
>>> what users are asking for and yocto advocates seem to push.
> 
> Try saying this in earshot of Tracey ;-). We are trying to do a better
> job of saying "Yocto Project", please help us!
> 
>>  Just watch the ELC
>>> videos for yocto related presentations, 'yocto' and 'poky' are used
>>> interchangeably in most of them.
>>>
>>> A 'reference' should be just that, a reference, not a mandated part.
>>
>> It's hard to call something Yocto Project based unless it used something from 
>> the Yocto Project.  meta-yocto being on of those components.
> 
> The criteria I see for being part of the Yocto Project are:
> 
> a) Sharing the project's objectives (e.g. making embedded Liunx 
>    development easier)
> b) Willing to be part of the Yocto Project's governance structure
> c) Bringing something new/beneficial to the Yocto Project (often with 
>    mutual benefit)
> d) Have some kind of sustainable resource plan
> 

I'll take a couple careful steps into this arena to offer just one more
possible criteria.

One of the touted goals/advantages/benefits of using the Yocto Project
is to work with a vetted set of sources that are known to all work
together, having had some level of QA performed. This is something the
poky repository accomplishes by bringing specifc versions of bitbake and
oe-core together (along with some other tooling). At some point, this
gets rolled up into a release of the Yocto Project: 0.9, 1.1, and soon
1.2. It's common for someone to refer to these release points as the
base for their BSP.

It therefor seems reasonable to me for a distribution definition (which
is how I think of Angstrom - but feel free to correct me Koen) to make a
statement like "This release of Angstrom builds with the Yocto Project
X.Y release."

I believe this is the sort of language that most outside developers
would immediately understand and associate with being part of the Yocto
Project.

--
Darren

> Note that it I don't list "must use meta-yocto" there since I don't
> think that is true.
> 
> I would want to be clear about where I'd see Angstrom positioned within
> the Yocto Project which would be as a reference binary distribution.
> 
> This is in contrast with Poky which would remain as the getting started
> and reference testing configuration (obviously building from
> source/sstate in contrast to Angstrom).
> 
> I do have some questions related to some of the above points but I'm
> going to hold off those for now and see where this discussion goes. I'd
> also mention that I'd like to see what advice the advisory board has on
> this topic too.
> 
>> There is enough confusion about yocto vs poky vs..  It's slowly being reconciled 
>> and defined.. but it's a slow process for all of us.
> 
> Right, I think we are getting to grips with this slowly and there was a
> good discussion about this on the meta-ti list recently.
> 
> Cheers,
> 
> Richard
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Moving angstrom under the yocto banner

[Koen Kooi]

Op 30 mrt. 2012, om 16:49 heeft Tom Rini het volgende geschreven:

> On Fri, Mar 30, 2012 at 11:06:04PM +0000, Stewart, David C wrote:
> 
>> Finally, Dr. Kooi has stated that he doesn't see YP as an upstream. In fact, many 
>> of the OSVs (like Wind River, Mentor Graphics and now ENEA - yeah!) absolutely
>> want to use YP as their upstream. So I'm hoping we could change the definition
>> of YP/Poky/Angstrom so Angstrom could us Poky as its upstream ... no? Too
>> hard?
> 
> Putting on my "me, myself and I" hat and apologizing for putting words
> in a few peoples mouths, I think this speaks to the heart of the problem
> Koen is trying to express.

Exactly! I said that *poky* is not an upstream, nothing about YP. 

>  On a technical level, the goal has been
> something (and I'm simplifying a bit here) to say that poky (the distro)
> is an implementation of policy for oe-core.  oe-core, bitbake and N
> number of other layers (meta-intel, meta-fsl-ppc, meta-ti, meta-java,
> meta-oe, meta-so-on-and-so-forth) will say that this is their metadata
> for release X.  Some of these layers (bitbake, oe-core, poky the distro)
> are maintained by 'Yocto Project' folks like Richard.  Others are
> maintained by community folks (Koen, Eric B.) or other companies
> (Denys).
> 
> Now, you say "YP is an upstream".  But "Yocto Project" is an upstream
> for bitbake, and for openembedded-core and for poky (the distro) and a
> lot of other stuff.  However, meta-yocto (what got us going in this
> direction) is only an upstream for poky (the distro), and Richard has
> said it's a TODO list item to move poky (the distro) into a separate
> repository and thus make meta-yocto ONLY a conglomeration of other
> repositories.
> 
> It's GOOD that companies want to work with upstream, and at some high
> level "Yocto Project" is where that is, in so far as bitbake,
> openembedded-core, etc, get a lot of time and energy and resources of
> "Yocto Project" people.  But these also get community resources too.
> Koen for example DOES see "Yocto Project" as an upstream in that he
> contributes to openembedded-core, etc, etc.  Angstrom also sees "Yocto
> Project" as an upstream for the same reasons.  But on a technical level,
> none of us would say it that way.

Exactly.  I said that *poky* is not an upstream.

> And this is where the confusion emanates from I believe.  You're saying
> that Angstrom (the distro) should see poky (the distro) as it's
> upstream.  If I was a runner, I could make an analogy you would say "but
> that's silly!" and I would say "exactly!" and we'd all be on the same
> page.  So can we pretend I did?
> 
>> Anyway, if we can't get to this level of interoperability, then adding Angstrom 
>> to the Yocto project may add too much confusion.
> 
> If someone makes a layer and it works with meta-yocto +
> meta-SomeHWVendor and fails with meta-angstrom + openembedded-core +
> bitbake + meta-SomeHWVendor (and you can replace meta-angstrom with
> meta-arago or any other layer that provides distro policy) it's a bug,
> not a feature, and not what anyone expects to happen today.

Like meta-ti won't build with binutils newer than 2.20.x. We all agree that's a bug in meta-ti, not a bug in oe-core or poky (the distro).

Re: Moving angstrom under the yocto banner

[Koen Kooi]

Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende geschreven:

[snip]

> On 03/30/2012 02:11 PM, Richard Purdie wrote:
>> 
>> The criteria I see for being part of the Yocto Project are:
>> 
>> a) Sharing the project's objectives (e.g. making embedded Liunx 
>>   development easier)
>> b) Willing to be part of the Yocto Project's governance structure
>> c) Bringing something new/beneficial to the Yocto Project (often with 
>>   mutual benefit)
>> d) Have some kind of sustainable resource plan
>> 
> 
> I'll take a couple careful steps into this arena to offer just one more
> possible criteria.
> 
> One of the touted goals/advantages/benefits of using the Yocto Project
> is to work with a vetted set of sources that are known to all work
> together, having had some level of QA performed. This is something the
> poky repository accomplishes by bringing specifc versions of bitbake and
> oe-core together (along with some other tooling). At some point, this
> gets rolled up into a release of the Yocto Project: 0.9, 1.1, and soon
> 1.2. It's common for someone to refer to these release points as the
> base for their BSP.
> 
> It therefor seems reasonable to me for a distribution definition (which
> is how I think of Angstrom - but feel free to correct me Koen) to make a
> statement like "This release of Angstrom builds with the Yocto Project
> X.Y release."

Yes, but see below

> I believe this is the sort of language that most outside developers
> would immediately understand and associate with being part of the Yocto
> Project.

What does a 'yocto project release' actually mean? Right now it looks more like a 'poky (the distro) release'. Since angstrom builds on oe-core and bitbake directly the statement (in the current situation) would be more like:

"This release of angstrom builds on oe-core 2012.1, bitbake 1.something.x, which matches the YP 1.x release".

If we move more things under the YP banner and convince subprojects to adopt the same schedule, we could make statements like:

"The Yocto Project 1.x release consist of the following modules:

* bitbake 1.x
* oe-core 2012.x
* poky $DOTT_character
* eglibc 2.17
* pseudo 1.2
* angstrom 2012.04
* meta-xilinx 6.5
... etc"

I think that would make it fit better with the "umbrella project" idea. "consists" might be a bad choice of words, I blame the unlimited coffee refills at the diner across the street :)

regards,

Koen

Re: Moving angstrom under the yocto banner

[Darren Hart]

On 03/30/2012 05:08 PM, Koen Kooi wrote:
> 
> Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende geschreven:
> 
> [snip]
> 
>> On 03/30/2012 02:11 PM, Richard Purdie wrote:
>>> 
>>> The criteria I see for being part of the Yocto Project are:
>>> 
>>> a) Sharing the project's objectives (e.g. making embedded Liunx 
>>> development easier) b) Willing to be part of the Yocto Project's
>>> governance structure c) Bringing something new/beneficial to the
>>> Yocto Project (often with mutual benefit) d) Have some kind of
>>> sustainable resource plan
>>> 
>> 
>> I'll take a couple careful steps into this arena to offer just one
>> more possible criteria.
>> 
>> One of the touted goals/advantages/benefits of using the Yocto
>> Project is to work with a vetted set of sources that are known to
>> all work together, having had some level of QA performed. This is
>> something the poky repository accomplishes by bringing specifc
>> versions of bitbake and oe-core together (along with some other
>> tooling). At some point, this gets rolled up into a release of the
>> Yocto Project: 0.9, 1.1, and soon 1.2. It's common for someone to
>> refer to these release points as the base for their BSP.
>> 
>> It therefor seems reasonable to me for a distribution definition
>> (which is how I think of Angstrom - but feel free to correct me
>> Koen) to make a statement like "This release of Angstrom builds
>> with the Yocto Project X.Y release."
> 
> Yes, but see below
> 
>> I believe this is the sort of language that most outside
>> developers would immediately understand and associate with being
>> part of the Yocto Project.
> 
> What does a 'yocto project release' actually mean? Right now it looks
> more like a 'poky (the distro) release'. Since angstrom builds on
> oe-core and bitbake directly the statement (in the current situation)
> would be more like:
> 

/me hands koen a real MUA that wraps at < 80 characters...
and wraps his mail for him...

(everyone else gets a pass, but you?  ;-)

I see the "poky" distro definition as only a part of the poky
repository, the naming is unfortunate, but I think we can all see past
that for the purposes of this discussion. This is part of meta-yocto
which will at some point be it's own repository.

So I don't agree with the assertion that it looks more like a "poky the
distro release".

> "This release of angstrom builds on oe-core 2012.1, bitbake
> 1.something.x, which matches the YP 1.x release".


OK. Donning my "Yeah but I have a XYZ and things to get done" hat, I
think people will respond more positively to:

"Download the 1.2 Yocto Project release, add meta-angstrom to your
bblayers.conf, and build $IMAGE_TARGET"

than they will to

Download bitbake X.Y, Angstrom X.Y, OE Core X.Y, etc. instructions on
setting up the layers, the local.conf, etc etc.

I believe there are some other details the poky repository helps out
with (someone more familiar with working with the individual components
would have to enumerate these, I honestly don't know what they all are).

And yes, there are the BSP layers to add to each of these scenarios, but
that effects each equally.

All that environment setup is something that can make or break the
initial experience. I believe lots of users appreciate not having to
pull all the pieces together themselves. (especially those that don't
even know what they're not having to do!)


> 
> If we move more things under the YP banner and convince subprojects
> to adopt the same schedule, we could make statements like:
> 
> "The Yocto Project 1.x release consist of the following modules:
> 
> * bitbake 1.x * oe-core 2012.x * poky $DOTT_character * eglibc 2.17 *
> pseudo 1.2 * angstrom 2012.04 * meta-xilinx 6.5 ... etc"
> 

With the exception of eglibc (I wouldn't want to have to list every
package from oe-core and the layers!) this doesn't seem out of line to me.

> I think that would make it fit better with the "umbrella project"
> idea. "consists" might be a bad choice of words, I blame the
> unlimited coffee refills at the diner across the street :)


And I blame any perceived snarkiness on the migraine and the 4 different
medications the doc's got me on to try and patch me up to fly on Monday ;-)


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Moving angstrom under the yocto banner

[Koen Kooi]

Op 30 mrt. 2012, om 17:28 heeft Darren Hart het volgende geschreven:

> 
> 
> On 03/30/2012 05:08 PM, Koen Kooi wrote:
>> 
>> Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende geschreven:
>> 
>> [snip]
>> 
>>> On 03/30/2012 02:11 PM, Richard Purdie wrote:
>>>> 
>>>> The criteria I see for being part of the Yocto Project are:
>>>> 
>>>> a) Sharing the project's objectives (e.g. making embedded Liunx 
>>>> development easier) b) Willing to be part of the Yocto Project's
>>>> governance structure c) Bringing something new/beneficial to the
>>>> Yocto Project (often with mutual benefit) d) Have some kind of
>>>> sustainable resource plan
>>>> 
>>> 
>>> I'll take a couple careful steps into this arena to offer just one
>>> more possible criteria.
>>> 
>>> One of the touted goals/advantages/benefits of using the Yocto
>>> Project is to work with a vetted set of sources that are known to
>>> all work together, having had some level of QA performed. This is
>>> something the poky repository accomplishes by bringing specifc
>>> versions of bitbake and oe-core together (along with some other
>>> tooling). At some point, this gets rolled up into a release of the
>>> Yocto Project: 0.9, 1.1, and soon 1.2. It's common for someone to
>>> refer to these release points as the base for their BSP.
>>> 
>>> It therefor seems reasonable to me for a distribution definition
>>> (which is how I think of Angstrom - but feel free to correct me
>>> Koen) to make a statement like "This release of Angstrom builds
>>> with the Yocto Project X.Y release."
>> 
>> Yes, but see below
>> 
>>> I believe this is the sort of language that most outside
>>> developers would immediately understand and associate with being
>>> part of the Yocto Project.
>> 
>> What does a 'yocto project release' actually mean? Right now it looks
>> more like a 'poky (the distro) release'. Since angstrom builds on
>> oe-core and bitbake directly the statement (in the current situation)
>> would be more like:
>> 
> 
> /me hands koen a real MUA that wraps at < 80 characters...
> and wraps his mail for him...
> 
> (everyone else gets a pass, but you?  ;-)
> 
> I see the "poky" distro definition as only a part of the poky
> repository, the naming is unfortunate, but I think we can all see past
> that for the purposes of this discussion. This is part of meta-yocto
> which will at some point be it's own repository.
> 
> So I don't agree with the assertion that it looks more like a "poky the
> distro release".

But it is the only component of the YP that gets released as part of the YP release, no?

>> "This release of angstrom builds on oe-core 2012.1, bitbake
>> 1.something.x, which matches the YP 1.x release".
> 
> 
> OK. Donning my "Yeah but I have a XYZ and things to get done" hat, I
> think people will respond more positively to:
> 
> "Download the 1.2 Yocto Project release, add meta-angstrom to your
> bblayers.conf, and build $IMAGE_TARGET"
> 
> than they will to
> 
> Download bitbake X.Y, Angstrom X.Y, OE Core X.Y, etc. instructions on
> setting up the layers, the local.conf, etc etc.
> 
> I believe there are some other details the poky repository helps out
> with (someone more familiar with working with the individual components
> would have to enumerate these, I honestly don't know what they all are).
> 
> And yes, there are the BSP layers to add to each of these scenarios, but
> that effects each equally.
> 
> All that environment setup is something that can make or break the
> initial experience. I believe lots of users appreciate not having to
> pull all the pieces together themselves. (especially those that don't
> even know what they're not having to do!)

And that's why angstrom (currently!) only supports setup using the angstrom setup-scripts. That contains all the logic that is needed to get the right versions. It also contains pretty much all known layers, so there's a high likelihood that users will never need to open bblayers.conf (either manually or using a script).

> If we move more things under the YP banner and convince subprojects
>> to adopt the same schedule, we could make statements like:
>> 
>> "The Yocto Project 1.x release consist of the following modules:
>> 
>> * bitbake 1.x * oe-core 2012.x * poky $DOTT_character * eglibc 2.17 *
>> pseudo 1.2 * angstrom 2012.04 * meta-xilinx 6.5 ... etc"
>> 
> 
> With the exception of eglibc (I wouldn't want to have to list every
> package from oe-core and the layers!) this doesn't seem out of line to me.

I was listing YP projects, not recipes/packages. I guess my point about a YP release needing to contain more than one yocto subproject got lost :(

>> I think that would make it fit better with the "umbrella project"
>> idea. "consists" might be a bad choice of words, I blame the
>> unlimited coffee refills at the diner across the street :)
> 
> 
> And I blame any perceived snarkiness on the migraine and the 4 different
> medications the doc's got me on to try and patch me up to fly on Monday ;-)

I hope you get well soon!

Re: Moving angstrom under the yocto banner

[Darren Hart]

On 03/30/2012 05:53 PM, Koen Kooi wrote:
> 
> Op 30 mrt. 2012, om 17:28 heeft Darren Hart het volgende geschreven:
> 
>> 
>> 
>> On 03/30/2012 05:08 PM, Koen Kooi wrote:
>>> 
>>> Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende
>>> geschreven:
>>> 
>>> [snip]
>>> 
>>>> On 03/30/2012 02:11 PM, Richard Purdie wrote:
>>>>> 
>>>>> The criteria I see for being part of the Yocto Project are:
>>>>> 
>>>>> a) Sharing the project's objectives (e.g. making embedded
>>>>> Liunx development easier) b) Willing to be part of the Yocto
>>>>> Project's governance structure c) Bringing something
>>>>> new/beneficial to the Yocto Project (often with mutual
>>>>> benefit) d) Have some kind of sustainable resource plan
>>>>> 
>>>> 
>>>> I'll take a couple careful steps into this arena to offer just
>>>> one more possible criteria.
>>>> 
>>>> One of the touted goals/advantages/benefits of using the Yocto 
>>>> Project is to work with a vetted set of sources that are known
>>>> to all work together, having had some level of QA performed.
>>>> This is something the poky repository accomplishes by bringing
>>>> specifc versions of bitbake and oe-core together (along with
>>>> some other tooling). At some point, this gets rolled up into a
>>>> release of the Yocto Project: 0.9, 1.1, and soon 1.2. It's
>>>> common for someone to refer to these release points as the base
>>>> for their BSP.
>>>> 
>>>> It therefor seems reasonable to me for a distribution
>>>> definition (which is how I think of Angstrom - but feel free to
>>>> correct me Koen) to make a statement like "This release of
>>>> Angstrom builds with the Yocto Project X.Y release."
>>> 
>>> Yes, but see below
>>> 
>>>> I believe this is the sort of language that most outside 
>>>> developers would immediately understand and associate with
>>>> being part of the Yocto Project.
>>> 
>>> What does a 'yocto project release' actually mean? Right now it
>>> looks more like a 'poky (the distro) release'. Since angstrom
>>> builds on oe-core and bitbake directly the statement (in the
>>> current situation) would be more like:
>>> 
>> 
>> /me hands koen a real MUA that wraps at < 80 characters... and
>> wraps his mail for him...
>> 
>> (everyone else gets a pass, but you?  ;-)
>> 
>> I see the "poky" distro definition as only a part of the poky 
>> repository, the naming is unfortunate, but I think we can all see
>> past that for the purposes of this discussion. This is part of
>> meta-yocto which will at some point be it's own repository.
>> 
>> So I don't agree with the assertion that it looks more like a "poky
>> the distro release".
> 
> But it is the only component of the YP that gets released as part of
> the YP release, no?
> 
>>> "This release of angstrom builds on oe-core 2012.1, bitbake 
>>> 1.something.x, which matches the YP 1.x release".
>> 
>> 
>> OK. Donning my "Yeah but I have a XYZ and things to get done" hat,
>> I think people will respond more positively to:
>> 
>> "Download the 1.2 Yocto Project release, add meta-angstrom to your 
>> bblayers.conf, and build $IMAGE_TARGET"
>> 
>> than they will to
>> 
>> Download bitbake X.Y, Angstrom X.Y, OE Core X.Y, etc. instructions
>> on setting up the layers, the local.conf, etc etc.
>> 
>> I believe there are some other details the poky repository helps
>> out with (someone more familiar with working with the individual
>> components would have to enumerate these, I honestly don't know
>> what they all are).
>> 
>> And yes, there are the BSP layers to add to each of these
>> scenarios, but that effects each equally.
>> 
>> All that environment setup is something that can make or break the 
>> initial experience. I believe lots of users appreciate not having
>> to pull all the pieces together themselves. (especially those that
>> don't even know what they're not having to do!)
> 
> And that's why angstrom (currently!) only supports setup using the
> angstrom setup-scripts. That contains all the logic that is needed to
> get the right versions. It also contains pretty much all known
> layers, so there's a high likelihood that users will never need to
> open bblayers.conf (either manually or using a script).
> 

CTRL+R

I wonder if there is something Angstrom could contribute to the Yocto
Project in terms of setup scripts...

>> If we move more things under the YP banner and convince
>> subprojects
>>> to adopt the same schedule, we could make statements like:
>>> 
>>> "The Yocto Project 1.x release consist of the following modules:
>>> 
>>> * bitbake 1.x * oe-core 2012.x * poky $DOTT_character * eglibc
>>> 2.17 * pseudo 1.2 * angstrom 2012.04 * meta-xilinx 6.5 ... etc"
>>> 
>> 
>> With the exception of eglibc (I wouldn't want to have to list
>> every package from oe-core and the layers!) this doesn't seem out
>> of line to me.
> 
> I was listing YP projects, not recipes/packages. I guess my point
> about a YP release needing to contain more than one yocto subproject
> got lost :(

Ah yes, and I missed that eglibc is indeed listed on the official list
of projects.

http://www.yoctoproject.org/projects

I don't think it's accurate to say that poky (the distro) is the only
Yocto Project project that is released in the official releases.

The list currently includes:
Poky (bitbake, oe-core, meta-yocto)
  Perhaps the description could be improved upon here.
Cross-Prelink
Eclipse IDE Plug-in
Pseudo
Swabber
AutoBuilder
Application Development Toolkit
Hob
Eglibc

Not all of these projects are part of the poky repository to be sure,
but that doesn't mean they aren't released with a Yocto Project release.
Some things like hob are part of bitbake with some scripts in poky. Some
of these are incorporated directly into oe-core. They could have been
done in meta-yocto instead.... but that wouldn't benefit as many people,
so it's a bit unfair then to only count things that are only in the poky
repository as being released with the Yocto Project release don't you think?

So that brings us back to what does it mean for Angstrom to be a Yocto
Project project I guess?

In my very humble opinion (really), it still makes sense to build
Angstrom with the components in the poky repository as part of a Yocto
Project release. I understand that there is resistance to this idea.
Angstrom has been independent from poky and the Yocto Project in the
past and I can understand not wanting to lose some of that
individuality. However, too much individuality breeds chaos and
fragmentation. These are the waters the Yocto Project is meant to help
people navigate. In my opinion, it is worth building with the poky
repository in order to gain the added cohesion that brings to all the
projects.

Again, this is my PERSONAL opinion. I don't speak in any official
capacity regarding criteria for being part of the Yocto Project, this is
just want makes sense to me.

> 
>>> I think that would make it fit better with the "umbrella
>>> project" idea. "consists" might be a bad choice of words, I blame
>>> the unlimited coffee refills at the diner across the street :)
>> 
>> 
>> And I blame any perceived snarkiness on the migraine and the 4
>> different medications the doc's got me on to try and patch me up to
>> fly on Monday ;-)
> 
> I hope you get well soon!

Thanks ;)

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Moving angstrom under the yocto banner

[Koen Kooi]

Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven:
> 
> So that brings us back to what does it mean for Angstrom to be a Yocto
> Project project I guess?
> 
> In my very humble opinion (really), it still makes sense to build
> Angstrom with the components in the poky repository as part of a Yocto
> Project release. I understand that there is resistance to this idea.

Yes, it would force angstrom developers to ignore upstream and work on 
downstream projects or as I will label them from now on: forks.

> Angstrom has been independent from poky and the Yocto Project in the
> past and I can understand not wanting to lose some of that
> individuality. However, too much individuality breeds chaos and
> fragmentation.

I will draw a line in the sand here and say: Forcing people to ignore 
upstream (oe-core/bitbake) and force a fork down their throats
breeds chaos and fragmentation.

I will again refer to the agreement between the OE community and yocto
for doing the 'merge'.

If you people (all speaking personally of course) really think poky is the only
way to go, then please close down and remove the oe-core and bitbake repos.

Re: Moving angstrom under the yocto banner

[Darren Hart]

On 03/30/2012 06:37 PM, Koen Kooi wrote:
> 
> Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven:
>>
>> So that brings us back to what does it mean for Angstrom to be a Yocto
>> Project project I guess?
>>
>> In my very humble opinion (really), it still makes sense to build
>> Angstrom with the components in the poky repository as part of a Yocto
>> Project release. I understand that there is resistance to this idea.
> 
> Yes, it would force angstrom developers to ignore upstream and work on 
> downstream projects 

That's an understandable concern. If I were a casual observer, I would
expect every project identifying itself with the Yocto Project to
interoperate with eachother at each release point. I would imagine that
Angstrom developers would continue their feature development with the
upstreams of bitbake and oe-core. As a Yocto Project release occurs (or
shortly after, as is the case with many BSPs) I would then expect (again
as a casual observer) that some effort went into ensuring some version
of Angstrom works with the release of the poky repository.

You've mentioned preferring to do this with set versions of bitbake and
oe-core. Do oe-core and bitbake maintain stable branches? I didn't think
they did. This makes it difficult to stabilize a release, and poky
serves this purpose well in my opinion. I'm going to stop going down
this path though as the policies surrounding this aren't clear to me and
would be better coming from others (RP or Chris for example).

Without this, people working with "The Yocto Project" are back to using
different versions of bitbake and oe-core depending on which
distribution or BSP they are building, and we ultimately end up where we
started with unsolvable dependency chains and people passing around
fixup patches for this or that issue.

> or as I will label them from now on: forks.
>
>> Angstrom has been independent from poky and the Yocto Project in the
>> past and I can understand not wanting to lose some of that
>> individuality. However, too much individuality breeds chaos and
>> fragmentation.
> 
> I will draw a line in the sand here and say: Forcing people to ignore 
> upstream (oe-core/bitbake) and force a fork down their throats
> breeds chaos and fragmentation.


Don't be so dramatic Koen :-) Everybody involved knows the bitbake and
oe-core in the poky repository are not forks, at least not in the sense
you portray here. They are snapshots with the same maintainer (or subset
of maintainers). They are no more "forks" than the stable Linux kernels
maintained by Greg KH are forks of Linus' kernel. I won't presume to
make a statement of policy regarding submitting patches against poky
that aren't also destined for oe-core or bitbake as well, but I
personally wouldn't deign to submit such a patch for fear of the wrath
of Purdie (and a flame or two from a certain dutchman ;-).


> I will again refer to the agreement between the OE community and yocto
> for doing the 'merge'.
> 
> If you people (all speaking personally of course) really think poky is the only
> way to go, then please close down and remove the oe-core and bitbake repos.


I see poky as collecting and integrating these projects into a
known-to-work-well-together snapshot. I suppose this is similar to what
the Angstrom setup scripts do, except the fetching is done for you in
poky instead of after the fact in Angstrom. I think this is a more
accurate description than calling them forks.

As I said, this was my personal opinion. RP and Jefro have both
expressed much looser views on what it should mean to be part of the
Yocto Project (and each carry more weight in this discussion than I). So
please don't use my comments as a reason not to pursue becoming "part of
the Yocto Project". As I said, I do not speak in any official capacity
as to what constitutes criteria. "We're just talking here" :-)

OK... time for more medication and some sleep... ugh.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Moving angstrom under the yocto banner

[Chris Larson]

On Fri, Mar 30, 2012 at 7:27 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 03/30/2012 06:37 PM, Koen Kooi wrote:
>>
>> Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven:
>>>
>>> So that brings us back to what does it mean for Angstrom to be a Yocto
>>> Project project I guess?
>>>
>>> In my very humble opinion (really), it still makes sense to build
>>> Angstrom with the components in the poky repository as part of a Yocto
>>> Project release. I understand that there is resistance to this idea.
>>
>> Yes, it would force angstrom developers to ignore upstream and work on
>> downstream projects
>
> That's an understandable concern. If I were a casual observer, I would
> expect every project identifying itself with the Yocto Project to
> interoperate with eachother at each release point. I would imagine that
> Angstrom developers would continue their feature development with the
> upstreams of bitbake and oe-core. As a Yocto Project release occurs (or
> shortly after, as is the case with many BSPs) I would then expect (again
> as a casual observer) that some effort went into ensuring some version
> of Angstrom works with the release of the poky repository.
>
> You've mentioned preferring to do this with set versions of bitbake and
> oe-core. Do oe-core and bitbake maintain stable branches? I didn't think
> they did. This makes it difficult to stabilize a release, and poky
> serves this purpose well in my opinion. I'm going to stop going down
> this path though as the policies surrounding this aren't clear to me and
> would be better coming from others (RP or Chris for example).
>
> Without this, people working with "The Yocto Project" are back to using
> different versions of bitbake and oe-core depending on which
> distribution or BSP they are building, and we ultimately end up where we
> started with unsolvable dependency chains and people passing around
> fixup patches for this or that issue.
>
>> or as I will label them from now on: forks.
>>
>>> Angstrom has been independent from poky and the Yocto Project in the
>>> past and I can understand not wanting to lose some of that
>>> individuality. However, too much individuality breeds chaos and
>>> fragmentation.
>>
>> I will draw a line in the sand here and say: Forcing people to ignore
>> upstream (oe-core/bitbake) and force a fork down their throats
>> breeds chaos and fragmentation.
>
>
> Don't be so dramatic Koen :-) Everybody involved knows the bitbake and
> oe-core in the poky repository are not forks, at least not in the sense
> you portray here. They are snapshots with the same maintainer (or subset
> of maintainers). They are no more "forks" than the stable Linux kernels
> maintained by Greg KH are forks of Linus' kernel. I won't presume to

Not to be terribly pendatic or difficult here, but technically, the
comparison you make here doesn't ring true. bitbake in poky *still*
has changes that never went into the upstream repository.
-- 
Christopher Larson

Re: Moving angstrom under the yocto banner

[Darren Hart]

On 03/30/2012 08:00 PM, Chris Larson wrote:
> On Fri, Mar 30, 2012 at 7:27 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>> On 03/30/2012 06:37 PM, Koen Kooi wrote:
>>>
>>> Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven:
>>>>
>>>> So that brings us back to what does it mean for Angstrom to be a Yocto
>>>> Project project I guess?
>>>>
>>>> In my very humble opinion (really), it still makes sense to build
>>>> Angstrom with the components in the poky repository as part of a Yocto
>>>> Project release. I understand that there is resistance to this idea.
>>>
>>> Yes, it would force angstrom developers to ignore upstream and work on
>>> downstream projects
>>
>> That's an understandable concern. If I were a casual observer, I would
>> expect every project identifying itself with the Yocto Project to
>> interoperate with eachother at each release point. I would imagine that
>> Angstrom developers would continue their feature development with the
>> upstreams of bitbake and oe-core. As a Yocto Project release occurs (or
>> shortly after, as is the case with many BSPs) I would then expect (again
>> as a casual observer) that some effort went into ensuring some version
>> of Angstrom works with the release of the poky repository.
>>
>> You've mentioned preferring to do this with set versions of bitbake and
>> oe-core. Do oe-core and bitbake maintain stable branches? I didn't think
>> they did. This makes it difficult to stabilize a release, and poky
>> serves this purpose well in my opinion. I'm going to stop going down
>> this path though as the policies surrounding this aren't clear to me and
>> would be better coming from others (RP or Chris for example).
>>
>> Without this, people working with "The Yocto Project" are back to using
>> different versions of bitbake and oe-core depending on which
>> distribution or BSP they are building, and we ultimately end up where we
>> started with unsolvable dependency chains and people passing around
>> fixup patches for this or that issue.
>>
>>> or as I will label them from now on: forks.
>>>
>>>> Angstrom has been independent from poky and the Yocto Project in the
>>>> past and I can understand not wanting to lose some of that
>>>> individuality. However, too much individuality breeds chaos and
>>>> fragmentation.
>>>
>>> I will draw a line in the sand here and say: Forcing people to ignore
>>> upstream (oe-core/bitbake) and force a fork down their throats
>>> breeds chaos and fragmentation.
>>
>>
>> Don't be so dramatic Koen :-) Everybody involved knows the bitbake and
>> oe-core in the poky repository are not forks, at least not in the sense
>> you portray here. They are snapshots with the same maintainer (or subset
>> of maintainers). They are no more "forks" than the stable Linux kernels
>> maintained by Greg KH are forks of Linus' kernel. I won't presume to
> 
> Not to be terribly pendatic or difficult here, but technically, the
> comparison you make here doesn't ring true. bitbake in poky *still*
> has changes that never went into the upstream repository.

I wasn't aware. Not knowing what they are, I'll have to leave a comment
on those to others.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Moving angstrom under the yocto banner

[Richard Purdie]

On Fri, 2012-03-30 at 20:00 -0700, Chris Larson wrote:
> Not to be terribly pendatic or difficult here, but technically, the
> comparison you make here doesn't ring true. bitbake in poky *still*
> has changes that never went into the upstream repository.

I was surprised to hear that but its easy enough to test:

diff -ur bitbake/ ../bitbake/
Only in bitbake//bin: bitbake-runtask
Only in ../bitbake/: classes
Only in ../bitbake/: conf
Only in ../bitbake/: .git
Only in ../bitbake/: .gitignore
diff -ur bitbake//lib/bb/cooker.py ../bitbake//lib/bb/cooker.py
--- bitbake//lib/bb/cooker.py	2012-03-22 14:40:40.488135297 +0000
+++ ../bitbake//lib/bb/cooker.py	2012-03-22 14:32:17.336127747 +0000
@@ -178,7 +178,7 @@
         self.configuration.data = bb.data.init()
 
         if not self.server_registration_cb:
-            bb.data.setVar("BB_WORKERCONTEXT", "1", self.configuration.data)
+            self.configuration.data.setVar("BB_WORKERCONTEXT", "1")
 
         filtered_keys = bb.utils.approved_variables()
         bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys)
Only in bitbake//lib/bb: shell.py
Only in ../bitbake/: MANIFEST.in
Only in ../bitbake/: setup.py
Only in ../bitbake/: TODO

(where one tree is on bitbake master and the other is poky master).

Of these, the classes/conf/.git/setup.py/MANIFEST/TODO are deliberately
removed. Those are upstream too. shell.py is still around as a reminder
that at some point I think we should resurrect it in a new form. I also
evidently never added bitbake-runtask upstream which I thought I had.

So, yes, there is a one line change that we've screwed up merging and
its not even functionally different.

Cheers,

Richard

Re: Moving angstrom under the yocto banner

[Frans Meulenbroeks]

Reading the discussion, I was wondering whether something under the
yocto umbrella should be self-contained layerwise.
E.g. would it be ok to depend on an external meta-whatsoever?

If so, this does have some quality implications, especially if the
external repo has higher prio and contains alternatives to recipes
that also exist in oe-core.

I can also imagine that any project brought under the yocto umbrella
would have to commit themselves to the yocto/oe-core guidelines.

My two cents.
Frans

Re: Moving angstrom under the yocto banner

[Paul Eggleton]

On Friday 30 March 2012 11:44:23 Koen Kooi wrote:
> The Angstrom core team would like to move angstrom under the yocto banner so
> we can formally claim to be 'yocto'.

I think a lot of points have been well addressed in this thread already, but I 
wanted to add (and reiterate) a few things. None of this constitutes Yocto 
Project policy, just my own opinions.

I think it's perfectly reasonable if you base something upon the openembedded-
core and bitbake repositories to state that it is based upon the Yocto Project 
(aside from any other conditions which Richard has already talked about; I'm 
sure LF has some trademark policies as well). If you're supplying your own 
distro policy as many will in their projects, you would not need to have meta-
yocto and it is reasonable if you are building a distribution such as Angstrom 
to want to exclude it, since you will never be using anything in it. Whatever 
you do though, I think you need to be able to demonstrate to your customers 
that you are in fact basing your release on top of a Yocto Project release.

This could be accomplished through the use of tags - if you state that you use 
BitBake x.y and a specific OE-Core tag, and this matches up with the Yocto 
Project release you state you have based upon, then that should be sufficient.

A few other thoughts:

1) Angstrom has a very distinct distro policy from the default provided by OE-
Core (or indeed the Poky distro policy); it also currently uses different 
versions of eglibc and the toolchain. This does make it for certain purposes a 
slightly different platform from Poky or something else based on OE-Core. This 
is not necessarily a problem, and is no doubt backed by sound reasoning, but 
is worth noting and communicating to users.

2) With Angstrom being primarily a binary distribution, I have the impression 
that you expect that that its distro policy will not be deviated from. There's 
definitely a good reason for this and value in having such a distribution; but 
users need to be able to understand the distinction. The Yocto Project itself 
in providing a way to produce custom Linux distributions does not have such 
restrictions - we expect that users will make whatever customisations make 
sense for their project, although of course we make some recommendations as to 
how they might be implemented.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Moving angstrom under the yocto banner

[Khem Raj]

On Fri, Mar 30, 2012 at 2:11 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2012-03-30 at 15:18 -0500, Mark Hatle wrote:
>> On 3/30/12 2:33 PM, Koen Kooi wrote:
>> >
>> > Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:
>> >
>> >> On 3/30/12 1:44 PM, Koen Kooi wrote:
>> >>> Hi,
>> >>>
>> >>> RP said I should raise this on the yocto lists, so here it is:
>> >>>
>> >>> The Angstrom core team would like to move angstrom under the yocto banner so
>> >>> we can formally claim to be 'yocto'.
>
> In the interests of clarity, as Tracey will tell you there is no
> "Yocto" (which is an SI prefix), only the "Yocto Project" :). I know
> some of us have bad habits but since we're trying to ensure we're all
> consistent, this is worth highlighting.
>
>> >> For it to be on the yocto project web site, it just need to have
>> the layers hosted on the git.yoctoproject.org.  But there is no
>> "yocto".. It's the Yocto Project, Poky, or specific git repositories.
>> There is no reason we can't have an angstrom repository.  It could be
>> in a similar format to the Poky repository (everything combined for a
>> single download), or it could be a layer [or layers] that sit on top
>> of Poky.
>> >
>> > Why on top of poky? I do not want poky, nor do my customers, oe-core is what
>> > we need and want. This proposal to move angstrom under yocto is targeted at
>> > eliminating 'poky' from the stack while still being able to say 'yocto'.
>>
>> Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a
>> distribution definition (in meta-yocto).  I assume angstrom has it's own
>> distribution definition.
>>
>> So my question is why NOT on top of Poky (the repository, not distribution
>> definition)?
>
> FWIW I don't think it has to be "on top of Poky".
>
> Basically the question is whether you'd include the meta-yocto layer or
> not. I know that doesn't have its own repository yet (but that's purely
> a time thing). I have no strong feelings either way about the inclusion
> of that layer. Its purposefully not got that much in it (one distro
> definition and some hardware/BSP addons).
>
> Also, Angstrom has a different repository format in the way the user
> fetches and interacts with layers. I don't think Yocto mandates any
> requirement in that area, or that it needs to.

I think the repository format used for poky in yocto project
could also be confusing things. Since it does not clone openembedded-core
or bitbake from upstream locations but maintains a copy of its own. even
though they are ditto copies of upstream it still has logical separation
that can be source of confusion. So if there was a meta-poky that defined
the distro policies and another integration layer that
sources openembedded-core and bitbake meta-poky and other layers
would make it much clearer.

As such OE-Core is distroless as we all know and can be built standalone
and poky uses most of defaults so meta-poky could be a thin layer on top
right now I think poky combines distro policy layer and integration
layer into one
which could also be source of confusion. I think creating distinct layers
for these two will clear up the air quite a bit.

Whether you want to include angstrom as an alternative distro layer is
Yocto project and angstrom community to decide I think this would make
the distinctions very clear.

-Khem

Re: Moving angstrom under the yocto banner

[Chris Larson]

On Sat, Mar 31, 2012 at 9:30 AM, Khem Raj <raj.khem@gmail.com> wrote:
> I think the repository format used for poky in yocto project
> could also be confusing things. Since it does not clone openembedded-core
> or bitbake from upstream locations but maintains a copy of its own. even
> though they are ditto copies of upstream it still has logical separation
> that can be source of confusion. So if there was a meta-poky that defined
> the distro policies and another integration layer that
> sources openembedded-core and bitbake meta-poky and other layers
> would make it much clearer.
>
> As such OE-Core is distroless as we all know and can be built standalone
> and poky uses most of defaults so meta-poky could be a thin layer on top
> right now I think poky combines distro policy layer and integration
> layer into one
> which could also be source of confusion. I think creating distinct layers
> for these two will clear up the air quite a bit.

I agree, and would love to see that happen.
-- 
Christopher Larson

Re: Moving angstrom under the yocto banner

[Matthew McClintock]

On Sat, Mar 31, 2012 at 12:06 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2012-03-30 at 20:00 -0700, Chris Larson wrote:
>> Not to be terribly pendatic or difficult here, but technically, the
>> comparison you make here doesn't ring true. bitbake in poky *still*
>> has changes that never went into the upstream repository.
>
> I was surprised to hear that but its easy enough to test:
>
> diff -ur bitbake/ ../bitbake/
> Only in bitbake//bin: bitbake-runtask
> Only in ../bitbake/: classes
> Only in ../bitbake/: conf
> Only in ../bitbake/: .git
> Only in ../bitbake/: .gitignore
> diff -ur bitbake//lib/bb/cooker.py ../bitbake//lib/bb/cooker.py
> --- bitbake//lib/bb/cooker.py   2012-03-22 14:40:40.488135297 +0000
> +++ ../bitbake//lib/bb/cooker.py        2012-03-22 14:32:17.336127747 +0000
> @@ -178,7 +178,7 @@
>         self.configuration.data = bb.data.init()
>
>         if not self.server_registration_cb:
> -            bb.data.setVar("BB_WORKERCONTEXT", "1", self.configuration.data)
> +            self.configuration.data.setVar("BB_WORKERCONTEXT", "1")
>
>         filtered_keys = bb.utils.approved_variables()
>         bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys)
> Only in bitbake//lib/bb: shell.py
> Only in ../bitbake/: MANIFEST.in
> Only in ../bitbake/: setup.py
> Only in ../bitbake/: TODO
>
> (where one tree is on bitbake master and the other is poky master).
>
> Of these, the classes/conf/.git/setup.py/MANIFEST/TODO are deliberately
> removed. Those are upstream too. shell.py is still around as a reminder
> that at some point I think we should resurrect it in a new form. I also
> evidently never added bitbake-runtask upstream which I thought I had.
>
> So, yes, there is a one line change that we've screwed up merging and
> its not even functionally different.

I think we should consider a "standard way" of integrating layers and
other bits. One method is (and I'm not recommending it) using 'git
submodules' - another is 'androids repo command'. If all the distros
(poky, angstrom, MEL, etc) could at least consider standardizing on
something like this it starts to becoming more obvious what exactly is
going on and what version of what is being pulled in and from where...

-M

Re: Moving angstrom under the yocto banner

[Richard Purdie]

On Sun, 2012-04-01 at 21:08 -0700, Matthew McClintock wrote:
> I think we should consider a "standard way" of integrating layers and
> other bits. One method is (and I'm not recommending it) using 'git
> submodules' - another is 'androids repo command'. If all the distros
> (poky, angstrom, MEL, etc) could at least consider standardizing on
> something like this it starts to becoming more obvious what exactly is
> going on and what version of what is being pulled in and from where...

I don't think there is common ground in this area to work with. There is
a certain class of users who really need a single repo with all the
pieces in to get started with. Poky and some of the solutions provided
by various people on this list look like that. There is also the
"scripts" approach taken by Angstrom and others and also the different
commercial offerings from the OSVs which are different again.

None of the implementations I've seen are wrong, they just help people
in different ways (and have some downsides too). Maybe in time we'll see
some standardisation in this area (we already have a small number of
approaches rather than everyone being different) but at the moment,
people are generally happy with their own solutions. I don't see much
value in trying to force a standard way of doing things. Its orders of
magnitude more important we share bitbake, OE-Core and make the layer
model a success.

Cheers,

Richard

Re: Moving angstrom under the yocto banner

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4340 bytes --]

On Fri, Mar 30, 2012 at 07:27:16PM -0700, Darren Hart wrote:

[snip]
> You've mentioned preferring to do this with set versions of bitbake and
> oe-core. Do oe-core and bitbake maintain stable branches? I didn't think
> they did. This makes it difficult to stabilize a release, and poky
> serves this purpose well in my opinion. I'm going to stop going down
> this path though as the policies surrounding this aren't clear to me and
> would be better coming from others (RP or Chris for example).

Again, the intention of poky the repository is not intended to have its
own changes.  oe-core will have a branch to go along with this release,
just like meta-oe, meta-ti, meta-fsl-arm, meta-fsl-ppc, meta-intel and
so forth.  Richard has even been (from how the branch layout looks) been
keeping master stable and doing master-next for things that will go in
post release.

I think at this point Richard (sorry!) really, really needs to find the
time to make poky the distro be a separate layer and Yocto adopt some
form of tooling, perhaps Angstrom's setup scripts with a little bit of
abstraction, to replace the conglomerate repository and stop some of the
confusion about repository directionality (and maybe move "I need to
resurrect idea X into a branch in upstream).  This could even be done as
part of Angstrom moving under the umbrella and one of the mutual
benefits :)

> Without this, people working with "The Yocto Project" are back to using
> different versions of bitbake and oe-core depending on which
> distribution or BSP they are building, and we ultimately end up where we
> started with unsolvable dependency chains and people passing around
> fixup patches for this or that issue.

Then perhaps non-SCM blobs should be part of a Yocto Project release.
The point is that poky the repository is NOT an upstream for anything
other than poky the distro specific things.`

> > or as I will label them from now on: forks.
> >
> >> Angstrom has been independent from poky and the Yocto Project in the
> >> past and I can understand not wanting to lose some of that
> >> individuality. However, too much individuality breeds chaos and
> >> fragmentation.
> > 
> > I will draw a line in the sand here and say: Forcing people to ignore 
> > upstream (oe-core/bitbake) and force a fork down their throats
> > breeds chaos and fragmentation.
> 
> Don't be so dramatic Koen :-) Everybody involved knows the bitbake and
> oe-core in the poky repository are not forks, at least not in the sense
> you portray here. They are snapshots with the same maintainer (or subset
> of maintainers). They are no more "forks" than the stable Linux kernels
> maintained by Greg KH are forks of Linus' kernel. I won't presume to
> make a statement of policy regarding submitting patches against poky
> that aren't also destined for oe-core or bitbake as well, but I
> personally wouldn't deign to submit such a patch for fear of the wrath
> of Purdie (and a flame or two from a certain dutchman ;-).

Yes, you the day to day developer understand the relationship between
bitbake, oe-core and poky the distro within poky the repository.  To the
casual or new developer it's not clear because it's not done with git
submodules or repo or other standard multi-git-repos-in-a-single-dir
tools.  It's just manual merge.

> > I will again refer to the agreement between the OE community and yocto
> > for doing the 'merge'.
> > 
> > If you people (all speaking personally of course) really think poky is the only
> > way to go, then please close down and remove the oe-core and bitbake repos.
> 
> 
> I see poky as collecting and integrating these projects into a
> known-to-work-well-together snapshot. I suppose this is similar to what
> the Angstrom setup scripts do, except the fetching is done for you in
> poky instead of after the fact in Angstrom. I think this is a more
> accurate description than calling them forks.

So lets be clear.  poky the repository is a collection of exiting
branches or tags from other projects, done as a "lets make this easy on
new / casual users".  So why should Angstrom be forced to include poky
the repository in it's work-flow when the exact same results, excluding
poky the distro, can be achieved by working upstream?

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Moving angstrom under the yocto banner

[Darren Hart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/02/2012 10:13 AM, Tom Rini wrote:
> On Fri, Mar 30, 2012 at 07:27:16PM -0700, Darren Hart wrote:
> 

Hi Tom,

> [snip]
>> You've mentioned preferring to do this with set versions of
>> bitbake and oe-core. Do oe-core and bitbake maintain stable
>> branches? I didn't think they did. This makes it difficult to
>> stabilize a release, and poky serves this purpose well in my
>> opinion. I'm going to stop going down this path though as the
>> policies surrounding this aren't clear to me and would be better
>> coming from others (RP or Chris for example).
> 
> Again, the intention of poky the repository is not intended to have
> its own changes.  oe-core will have a branch to go along with this
> release, just like meta-oe, meta-ti, meta-fsl-arm, meta-fsl-ppc,
> meta-intel and so forth.  Richard has even been (from how the
> branch layout looks) been keeping master stable and doing
> master-next for things that will go in post release.
> 
> I think at this point Richard (sorry!) really, really needs to find
> the time to make poky the distro be a separate layer and Yocto
> adopt some form of tooling, perhaps Angstrom's setup scripts with a
> little bit of abstraction, to replace the conglomerate repository
> and stop some of the


That's been stated by RP himself and think we're all agreed on it.


> confusion about repository directionality (and maybe move "I need
> to resurrect idea X into a branch in upstream).  This could even be
> done as part of Angstrom moving under the umbrella and one of the
> mutual benefits :)
> 
>> Without this, people working with "The Yocto Project" are back to
>> using different versions of bitbake and oe-core depending on
>> which distribution or BSP they are building, and we ultimately
>> end up where we started with unsolvable dependency chains and
>> people passing around fixup patches for this or that issue.
> 
> Then perhaps non-SCM blobs should be part of a Yocto Project
> release.


That has been suggested and it has some merit as a deployment
mechanism. I do fear that people will find it convenient to  get
started, but the confusion is just being pushed back a level to when
they try to start developing. Which perhaps is an improvement, but I
think we can do better.


> The point is that poky the repository is NOT an upstream for
> anything other than poky the distro specific things.`


I've wondered about this myself. One disadvantage of this approach in
my opinion, and an advantage of the poky repository, is that in poky
we have a sort of buffer between oe-core development and bitbake
development, where the two can be made to coexist in a known good
state. That said, as a developer I would love not having to develop
against poky and then split my patches out across the various
upstreams (bitbake, oe-core, and meta-yocto) and hope they don't have
to be rebased.

However, I fear developing on master of each oe-core and bitbake would
prove much more fragile than working on poky's master. For stable
releases, this issue can be addresses with a similar branching and
tagging scheme in oe-core and bitbake (and other Yocto Project
projects such as meta-yocto, meta-intel, angstrom, meta-ti, etc.)


> 
>>> or as I will label them from now on: forks.
>>> 
>>>> Angstrom has been independent from poky and the Yocto Project
>>>> in the past and I can understand not wanting to lose some of
>>>> that individuality. However, too much individuality breeds
>>>> chaos and fragmentation.
>>> 
>>> I will draw a line in the sand here and say: Forcing people to
>>> ignore upstream (oe-core/bitbake) and force a fork down their
>>> throats breeds chaos and fragmentation.
>> 
>> Don't be so dramatic Koen :-) Everybody involved knows the
>> bitbake and oe-core in the poky repository are not forks, at
>> least not in the sense you portray here. They are snapshots with
>> the same maintainer (or subset of maintainers). They are no more
>> "forks" than the stable Linux kernels maintained by Greg KH are
>> forks of Linus' kernel. I won't presume to make a statement of
>> policy regarding submitting patches against poky that aren't also
>> destined for oe-core or bitbake as well, but I personally
>> wouldn't deign to submit such a patch for fear of the wrath of
>> Purdie (and a flame or two from a certain dutchman ;-).
> 
> Yes, you the day to day developer understand the relationship
> between bitbake, oe-core and poky the distro within poky the
> repository.  To the casual or new developer it's not clear because
> it's not done with git submodules or repo or other standard
> multi-git-repos-in-a-single-dir tools.  It's just manual merge.


I agree that it's confusing to "the casual or new developer". In
particular my concern is about what it means to "build with the Yocto
Project X.Y release". When such a person goes to download a BSP, say
from the Yocto Project Downloads page or somewhere else, that BSP
should provide some statement about what it works with. The convenient
"works with" statement is "works with the Yocto Project X.Y release".
So what does that mean?

Poky has such tags and branches in the repository and there are
tarball releases which make it easy for such a person to download and
get started. I think the poky repository is valuable in this sense. It
is possible that this could be made to work with some additional
scripting in the poky setup scripts to fetch a tag of bitbake and
oe-core, but there would need to be some means of stabilizing these.
Release branches address this for stable releases, but I'm not sure
how this would be accomplished with the master branch.

Anyone have any brilliant ideas there?

> 
>>> I will again refer to the agreement between the OE community
>>> and yocto for doing the 'merge'.
>>> 
>>> If you people (all speaking personally of course) really think
>>> poky is the only way to go, then please close down and remove
>>> the oe-core and bitbake repos.
>> 
>> 
>> I see poky as collecting and integrating these projects into a 
>> known-to-work-well-together snapshot. I suppose this is similar
>> to what the Angstrom setup scripts do, except the fetching is
>> done for you in poky instead of after the fact in Angstrom. I
>> think this is a more accurate description than calling them
>> forks.
> 
> So lets be clear.  poky the repository is a collection of exiting 
> branches or tags from other projects, done as a "lets make this
> easy on new / casual users".  So why should Angstrom be forced to
> include poky the repository in it's work-flow when the exact same
> results, excluding poky the distro, can be achieved by working
> upstream?

Clear reproducible testing results. Whether or not a pair of git
clones and some tinkering can result in the same thing as a poky
repository or not isn't relevant in my opinion. I believe that we need
a consistent mode of validating support for a Yocto Project X.Y
release. Now if that is accomplished by building with the poky
repository of the same vintage or by running some script that pulls
the right bits together independently.... I honestly don't care, but I
do think it should be consistent.

Perhaps the poky repository becomes that canonical validation tool.
Perhaps not.

- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPex69AAoJEKbMaAwKp364M0sH/1BKQQaauN1pmmuJzlPlObjp
azICDtyUaQ9ih8b580Y7ioiBQnMpMmYGG+S272dcQz65rDMS20yeahr5Q3cMdKxr
Ur04AsAwyVTU8ZUvkcOtaEAN0XzRoI5N/602uWetGlDiRdaLlQE96dMGztMjNgH9
ZUMoj2Ht+BU0BoOD0lnNCh3EtWoAsitzlX5whcUUdlzEoDeeeIm7V6iobEaSaZ2z
6E0Pg3i+CeXHl7CCaRLc20I0PwBEs48Wk2RBBANYcSxGceDOnXwbz01oUm8/0aa5
YMRiE1n6/YazxA30lU6SreqYBtWed8oozWXRwqHjsbN2/XjOO6Fg18Uxmbgcyo0=
=Am0D
-----END PGP SIGNATURE-----

Re: Moving angstrom under the yocto banner

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Clear reproducible testing results. Whether or not a pair of git
> clones and some tinkering can result in the same thing as a poky
> repository or not isn't relevant in my opinion. I believe that we need
> a consistent mode of validating support for a Yocto Project X.Y
> release. Now if that is accomplished by building with the poky
> repository of the same vintage or by running some script that pulls
> the right bits together independently.... I honestly don't care, but I
> do think it should be consistent.

so teach setup script something like:
poky.sh checkout X.Y (which checkouts whatever parts are needed for X.Y)
poky.sh update X.Y   (dtto)

Which creates the same structure like poky repository has, but by
checkouting upstream repositories or using submodules or whatever.

That's what oebb.sh and SHR makefile does for master/shr HEADs, but can
be extended do it for particular version too.

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Moving angstrom under the yocto banner

[Darren Hart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 04/03/2012 09:25 AM, Martin Jansa wrote:
> On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Clear reproducible testing
>> results. Whether or not a pair of git clones and some tinkering
>> can result in the same thing as a poky repository or not isn't
>> relevant in my opinion. I believe that we need a consistent mode
>> of validating support for a Yocto Project X.Y release. Now if
>> that is accomplished by building with the poky repository of the
>> same vintage or by running some script that pulls the right bits
>> together independently.... I honestly don't care, but I do think
>> it should be consistent.
> 
> so teach setup script something like: poky.sh checkout X.Y (which
> checkouts whatever parts are needed for X.Y) poky.sh update X.Y
> (dtto)
> 
> Which creates the same structure like poky repository has, but by 
> checkouting upstream repositories or using submodules or whatever.
> 
> That's what oebb.sh and SHR makefile does for master/shr HEADs, but
> can be extended do it for particular version too.
> 


This is certainly doable, but it doesn't address the stabilization
buffer poky provides that I mentioned.

- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPeyYbAAoJEKbMaAwKp364OUMH/j8LTjnxSHNS7bc2oDQXmx3r
E/HzG2t2Q+u0N7Zg/H/1OHNjmZesDr94GlnqHzVMOQRXdpmnx/BZjLuTCL//R43Y
wP3jH/gCrAqdk2EJmqNkNQN3A5iQT8Ybj9dYfd0tr6M+GnN/9MpaL8VyW1Fz3Rxo
gHgxNu+mvB8mKT4Ix45a91yV107LQ2enPZ7OHHURLGRdjxF1SCi0owuP/hQzEAYl
qdgrc3KeBcrAs9ubC9OyAg68G7N8kvgSNSQRegVcELRa34k5Lr/6uP7pehT0IY4m
meA1E3tGafo1iIpdxSHhM6HwzUwKcWf/RzupGcXXUWuHsVgeaElvUW5u0h7Kkkg=
=mdcZ
-----END PGP SIGNATURE-----

Re: Moving angstrom under the yocto banner

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/03/2012 09:25 AM, Martin Jansa wrote:
> > On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Clear reproducible testing
> >> results. Whether or not a pair of git clones and some tinkering
> >> can result in the same thing as a poky repository or not isn't
> >> relevant in my opinion. I believe that we need a consistent mode
> >> of validating support for a Yocto Project X.Y release. Now if
> >> that is accomplished by building with the poky repository of the
> >> same vintage or by running some script that pulls the right bits
> >> together independently.... I honestly don't care, but I do think
> >> it should be consistent.
> > 
> > so teach setup script something like: poky.sh checkout X.Y (which
> > checkouts whatever parts are needed for X.Y) poky.sh update X.Y
> > (dtto)
> > 
> > Which creates the same structure like poky repository has, but by 
> > checkouting upstream repositories or using submodules or whatever.
> > 
> > That's what oebb.sh and SHR makefile does for master/shr HEADs, but
> > can be extended do it for particular version too.
> 
> 
> This is certainly doable, but it doesn't address the stabilization
> buffer poky provides that I mentioned.

While I want to reply to your whole email, I want to ask now, is there
really a stabilization buffer being provided?  I could see that being
the case if we were talking about depending on something independent of
this effort (gcc, eglibc, make) but we're talking about oe-core and
bitbake.  The folks in charge of poky the repo are in charge of oe-core
and bitbake.  There might be an unintentional lag between when Richard
can push changes to poky the repo, but I don't think it's great (and
hey, freeing up Richard's time for other stuff is probably a good thing
:)).

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Moving angstrom under the yocto banner

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> On 04/03/2012 09:25 AM, Martin Jansa wrote:
> > On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Clear reproducible testing
> >> results. Whether or not a pair of git clones and some tinkering
> >> can result in the same thing as a poky repository or not isn't
> >> relevant in my opinion. I believe that we need a consistent mode
> >> of validating support for a Yocto Project X.Y release. Now if
> >> that is accomplished by building with the poky repository of the
> >> same vintage or by running some script that pulls the right bits
> >> together independently.... I honestly don't care, but I do think
> >> it should be consistent.
> > 
> > so teach setup script something like: poky.sh checkout X.Y (which
> > checkouts whatever parts are needed for X.Y) poky.sh update X.Y
> > (dtto)
> > 
> > Which creates the same structure like poky repository has, but by 
> > checkouting upstream repositories or using submodules or whatever.
> > 
> > That's what oebb.sh and SHR makefile does for master/shr HEADs, but
> > can be extended do it for particular version too.
> > 
> 
> 
> This is certainly doable, but it doesn't address the stabilization
> buffer poky provides that I mentioned.

And is it?
OE @ ~ $ diff -rq openembedded-core/ projects/poky/ | grep -v '\.git'
Files openembedded-core/README and projects/poky/README differ
Only in projects/poky/: README.hardware
Only in projects/poky/: bitbake
Only in openembedded-core/: dev
Only in projects/poky/: documentation
Only in openembedded-core/meta/conf: bblayers.conf.sample
Only in openembedded-core/meta/conf: local.conf.sample
Only in openembedded-core/meta/conf: local.conf.sample.extended
Only in openembedded-core/meta/conf: site.conf.sample
Only in projects/poky/: meta-yocto
Only in projects/poky/scripts: lib
Files openembedded-core/scripts/oe-setup-builddir and projects/poky/scripts/oe-setup-builddir differ
Only in projects/poky/scripts: yocto-bsp
Only in projects/poky/scripts: yocto-kernel

OE @ ~ $ diff -rq projects/bitbake/ projects/poky/bitbake/ | grep -v '\.git'
Only in projects/bitbake/: MANIFEST.in
Only in projects/bitbake/: TODO
Only in projects/poky/bitbake/bin: bitbake-runtask
Only in projects/bitbake/: classes
Only in projects/bitbake/: conf
Only in projects/bitbake/lib/bb: fetch
Only in projects/poky/bitbake/lib/bb: shell.py
Only in projects/bitbake/: setup.py

Those changes doesn't look like stabilization buffer.. which is fine we don't need 
bigger diff between oe-core repo and poky copy, smaller would be nice.

And "dangerous" changes are stopped to oe-core AFAIK, see e.g. my 13 pending patches...

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Moving angstrom under the yocto banner

[Darren Hart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 04/03/2012 09:40 AM, Tom Rini wrote:
> On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 04/03/2012 09:25 AM, Martin Jansa wrote:
>>> On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Clear reproducible
>>>> testing results. Whether or not a pair of git clones and some
>>>> tinkering can result in the same thing as a poky repository
>>>> or not isn't relevant in my opinion. I believe that we need a
>>>> consistent mode of validating support for a Yocto Project X.Y
>>>> release. Now if that is accomplished by building with the
>>>> poky repository of the same vintage or by running some script
>>>> that pulls the right bits together independently.... I
>>>> honestly don't care, but I do think it should be consistent.
>>> 
>>> so teach setup script something like: poky.sh checkout X.Y
>>> (which checkouts whatever parts are needed for X.Y) poky.sh
>>> update X.Y (dtto)
>>> 
>>> Which creates the same structure like poky repository has, but
>>> by checkouting upstream repositories or using submodules or
>>> whatever.
>>> 
>>> That's what oebb.sh and SHR makefile does for master/shr HEADs,
>>> but can be extended do it for particular version too.
>> 
>> 
>> This is certainly doable, but it doesn't address the
>> stabilization buffer poky provides that I mentioned.
> 
> While I want to reply to your whole email, I want to ask now, is
> there really a stabilization buffer being provided?  I could see
> that being the case if we were talking about depending on something
> independent of this effort (gcc, eglibc, make) but we're talking
> about oe-core and bitbake.  The folks in charge of poky the repo
> are in charge of oe-core and bitbake.  There might be an
> unintentional lag between when Richard can push changes to poky the
> repo, but I don't think it's great (and hey, freeing up Richard's
> time for other stuff is probably a good thing :)).
> 

I believe there is. It's a small temporal buffer though. I'd be
interested in RP's thoughts here.

- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPey5MAAoJEKbMaAwKp364g7oH/RJxQqfOJpCdIz4qaC81hQWt
u0SUBpqS4FEUMT5JCgxRztaKsq8+irFTYUODvEDzVTDY8hJJ7rd+QKKnYlgSFT1o
vB9qerea1fQZMEAw0J1CmXRCD9tuBN7nMec6Z36KIcJXp0KrAZrSMzgF20byeGTf
YjusfkiNOIdVt3q1AtESlQbbAzmiFlvlGxSn4v8hLtXzL36XGyQ//1Lg1mr1ZXvm
rqEgN3bA4CdI/tgg6AMjOAI0KnXKj2tWn7o4Gule9pcRycg18XdE+iGZGmSxDdGM
+4gE54rwQlrM/2cMM3n0qhzqAyB4o8vnsvPBQyt+DXCy6ErAaqnP25Y31rW7EvY=
=MpXf
-----END PGP SIGNATURE-----

Re: Moving angstrom under the yocto banner

[Darren Hart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 04/03/2012 09:44 AM, Martin Jansa wrote:
> On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> 
>> 
>> On 04/03/2012 09:25 AM, Martin Jansa wrote:
>>> On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Clear reproducible
>>>> testing results. Whether or not a pair of git clones and some
>>>> tinkering can result in the same thing as a poky repository
>>>> or not isn't relevant in my opinion. I believe that we need a
>>>> consistent mode of validating support for a Yocto Project X.Y
>>>> release. Now if that is accomplished by building with the
>>>> poky repository of the same vintage or by running some script
>>>> that pulls the right bits together independently.... I
>>>> honestly don't care, but I do think it should be consistent.
>>> 
>>> so teach setup script something like: poky.sh checkout X.Y
>>> (which checkouts whatever parts are needed for X.Y) poky.sh
>>> update X.Y (dtto)
>>> 
>>> Which creates the same structure like poky repository has, but
>>> by checkouting upstream repositories or using submodules or
>>> whatever.
>>> 
>>> That's what oebb.sh and SHR makefile does for master/shr HEADs,
>>> but can be extended do it for particular version too.
>>> 
>> 
>> 
>> This is certainly doable, but it doesn't address the
>> stabilization buffer poky provides that I mentioned.
> 
> And is it? OE @ ~ $ diff -rq openembedded-core/ projects/poky/ |
> grep -v '\.git' Files openembedded-core/README and
> projects/poky/README differ Only in projects/poky/:
> README.hardware Only in projects/poky/: bitbake Only in
> openembedded-core/: dev Only in projects/poky/: documentation Only
> in openembedded-core/meta/conf: bblayers.conf.sample Only in
> openembedded-core/meta/conf: local.conf.sample Only in
> openembedded-core/meta/conf: local.conf.sample.extended Only in
> openembedded-core/meta/conf: site.conf.sample Only in
> projects/poky/: meta-yocto Only in projects/poky/scripts: lib Files
> openembedded-core/scripts/oe-setup-builddir and
> projects/poky/scripts/oe-setup-builddir differ Only in
> projects/poky/scripts: yocto-bsp Only in projects/poky/scripts:
> yocto-kernel
> 
> OE @ ~ $ diff -rq projects/bitbake/ projects/poky/bitbake/ | grep
> -v '\.git' Only in projects/bitbake/: MANIFEST.in Only in
> projects/bitbake/: TODO Only in projects/poky/bitbake/bin:
> bitbake-runtask Only in projects/bitbake/: classes Only in
> projects/bitbake/: conf Only in projects/bitbake/lib/bb: fetch Only
> in projects/poky/bitbake/lib/bb: shell.py Only in
> projects/bitbake/: setup.py
> 
> Those changes doesn't look like stabilization buffer.. which is
> fine we don't need bigger diff between oe-core repo and poky copy,
> smaller would be nice.
> 
> And "dangerous" changes are stopped to oe-core AFAIK, see e.g. my
> 13 pending patches...
> 
> Cheers,
> 

I expect the buffer to be empty at times. Hopefully *MOST* of the time.

- -- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPey6cAAoJEKbMaAwKp364o9YIAK8aUDP2jj4Nf1YeefhvZyrm
kI5EID7AF1ROjItOX2oQJjLj7aZDsiXCTzx7HFOv1L2VHm1j/6cEtyHkXHwKNFlN
ZMWqH2q3+ImUeb6PR2E1PH41KMZoleQtvtQZQQz1cnmn2rjxAI0bJV+3gMcxmugg
XO0L7uj0/O1LS/F+s4eCFe7k4VnglzuHyeL4ZIqrBOqGdfawl8vs+iMRaeMhUatX
guu42fTZJDulKTaymsYf8pkz6vWfNsz4Nivt101ofcAcWLABxDqVwCk3nnX7j6m7
yO5AldHi19IgcSUNncqdWkIrecQpoSSGB5s4S52i4xHKpM1VwhmtiSfiP+8r7Wk=
=qtXk
-----END PGP SIGNATURE-----

Re: Moving angstrom under the yocto banner

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]

On Tue, Apr 03, 2012 at 10:08:44AM -0700, Darren Hart wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 04/03/2012 09:44 AM, Martin Jansa wrote:
> > On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> On 04/03/2012 09:25 AM, Martin Jansa wrote:
> >>> On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Clear reproducible
> >>>> testing results. Whether or not a pair of git clones and some
> >>>> tinkering can result in the same thing as a poky repository
> >>>> or not isn't relevant in my opinion. I believe that we need a
> >>>> consistent mode of validating support for a Yocto Project X.Y
> >>>> release. Now if that is accomplished by building with the
> >>>> poky repository of the same vintage or by running some script
> >>>> that pulls the right bits together independently.... I
> >>>> honestly don't care, but I do think it should be consistent.
> >>> 
> >>> so teach setup script something like: poky.sh checkout X.Y
> >>> (which checkouts whatever parts are needed for X.Y) poky.sh
> >>> update X.Y (dtto)
> >>> 
> >>> Which creates the same structure like poky repository has, but
> >>> by checkouting upstream repositories or using submodules or
> >>> whatever.
> >>> 
> >>> That's what oebb.sh and SHR makefile does for master/shr HEADs,
> >>> but can be extended do it for particular version too.
> >>> 
> >> 
> >> 
> >> This is certainly doable, but it doesn't address the
> >> stabilization buffer poky provides that I mentioned.
> > 
> > And is it? OE @ ~ $ diff -rq openembedded-core/ projects/poky/ |
> > grep -v '\.git' Files openembedded-core/README and
> > projects/poky/README differ Only in projects/poky/:
> > README.hardware Only in projects/poky/: bitbake Only in
> > openembedded-core/: dev Only in projects/poky/: documentation Only
> > in openembedded-core/meta/conf: bblayers.conf.sample Only in
> > openembedded-core/meta/conf: local.conf.sample Only in
> > openembedded-core/meta/conf: local.conf.sample.extended Only in
> > openembedded-core/meta/conf: site.conf.sample Only in
> > projects/poky/: meta-yocto Only in projects/poky/scripts: lib Files
> > openembedded-core/scripts/oe-setup-builddir and
> > projects/poky/scripts/oe-setup-builddir differ Only in
> > projects/poky/scripts: yocto-bsp Only in projects/poky/scripts:
> > yocto-kernel
> > 
> > OE @ ~ $ diff -rq projects/bitbake/ projects/poky/bitbake/ | grep
> > -v '\.git' Only in projects/bitbake/: MANIFEST.in Only in
> > projects/bitbake/: TODO Only in projects/poky/bitbake/bin:
> > bitbake-runtask Only in projects/bitbake/: classes Only in
> > projects/bitbake/: conf Only in projects/bitbake/lib/bb: fetch Only
> > in projects/poky/bitbake/lib/bb: shell.py Only in
> > projects/bitbake/: setup.py
> > 
> > Those changes doesn't look like stabilization buffer.. which is
> > fine we don't need bigger diff between oe-core repo and poky copy,
> > smaller would be nice.
> > 
> > And "dangerous" changes are stopped to oe-core AFAIK, see e.g. my
> > 13 pending patches...
> 
> I expect the buffer to be empty at times. Hopefully *MOST* of the time.

I really think what you're calling a stabilization buffer is what others
of us see when we branch the repo(s) we're working on until we're happy
with the changes.

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Moving angstrom under the yocto banner

[Chris Larson]

On Tue, Apr 3, 2012 at 10:15 AM, Tom Rini <tom.rini@gmail.com> wrote:
> On Tue, Apr 03, 2012 at 10:08:44AM -0700, Darren Hart wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On 04/03/2012 09:44 AM, Martin Jansa wrote:
>> > On Tue, Apr 03, 2012 at 09:32:27AM -0700, Darren Hart wrote:
>> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> >> On 04/03/2012 09:25 AM, Martin Jansa wrote:
>> >>> On Tue, Apr 03, 2012 at 09:01:01AM -0700, Darren Hart wrote:
>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Clear reproducible
>> >>>> testing results. Whether or not a pair of git clones and some
>> >>>> tinkering can result in the same thing as a poky repository
>> >>>> or not isn't relevant in my opinion. I believe that we need a
>> >>>> consistent mode of validating support for a Yocto Project X.Y
>> >>>> release. Now if that is accomplished by building with the
>> >>>> poky repository of the same vintage or by running some script
>> >>>> that pulls the right bits together independently.... I
>> >>>> honestly don't care, but I do think it should be consistent.
>> >>>
>> >>> so teach setup script something like: poky.sh checkout X.Y
>> >>> (which checkouts whatever parts are needed for X.Y) poky.sh
>> >>> update X.Y (dtto)
>> >>>
>> >>> Which creates the same structure like poky repository has, but
>> >>> by checkouting upstream repositories or using submodules or
>> >>> whatever.
>> >>>
>> >>> That's what oebb.sh and SHR makefile does for master/shr HEADs,
>> >>> but can be extended do it for particular version too.
>> >>>
>> >>
>> >>
>> >> This is certainly doable, but it doesn't address the
>> >> stabilization buffer poky provides that I mentioned.
>> >
>> > And is it? OE @ ~ $ diff -rq openembedded-core/ projects/poky/ |
>> > grep -v '\.git' Files openembedded-core/README and
>> > projects/poky/README differ Only in projects/poky/:
>> > README.hardware Only in projects/poky/: bitbake Only in
>> > openembedded-core/: dev Only in projects/poky/: documentation Only
>> > in openembedded-core/meta/conf: bblayers.conf.sample Only in
>> > openembedded-core/meta/conf: local.conf.sample Only in
>> > openembedded-core/meta/conf: local.conf.sample.extended Only in
>> > openembedded-core/meta/conf: site.conf.sample Only in
>> > projects/poky/: meta-yocto Only in projects/poky/scripts: lib Files
>> > openembedded-core/scripts/oe-setup-builddir and
>> > projects/poky/scripts/oe-setup-builddir differ Only in
>> > projects/poky/scripts: yocto-bsp Only in projects/poky/scripts:
>> > yocto-kernel
>> >
>> > OE @ ~ $ diff -rq projects/bitbake/ projects/poky/bitbake/ | grep
>> > -v '\.git' Only in projects/bitbake/: MANIFEST.in Only in
>> > projects/bitbake/: TODO Only in projects/poky/bitbake/bin:
>> > bitbake-runtask Only in projects/bitbake/: classes Only in
>> > projects/bitbake/: conf Only in projects/bitbake/lib/bb: fetch Only
>> > in projects/poky/bitbake/lib/bb: shell.py Only in
>> > projects/bitbake/: setup.py
>> >
>> > Those changes doesn't look like stabilization buffer.. which is
>> > fine we don't need bigger diff between oe-core repo and poky copy,
>> > smaller would be nice.
>> >
>> > And "dangerous" changes are stopped to oe-core AFAIK, see e.g. my
>> > 13 pending patches...
>>
>> I expect the buffer to be empty at times. Hopefully *MOST* of the time.
>
> I really think what you're calling a stabilization buffer is what others
> of us see when we branch the repo(s) we're working on until we're happy
> with the changes.

I really don't see what the issue is here. If you want a stable
branch, we can look into creating such a thing upstream, though I'm
personally of the opinion that master should remain release-quality,
and make better use of feature branches, potentially a
next/integration branch for forthcoming features, than trying to
cherry pick onto a "stable" branch. There's nothing poky's structure
provides that can't also be provided via branching policy in the
individual repositories.
-- 
Christopher Larson

Re: Moving angstrom under the yocto banner

[Brian Hutchinson]

On Tue, Apr 3, 2012 at 1:26 PM, Chris Larson <clarson@kergoth.com> wrote:
> I really don't see what the issue is here. If you want a stable
> branch, we can look into creating such a thing upstream, though I'm
> personally of the opinion that master should remain release-quality,
> and make better use of feature branches, potentially a
> next/integration branch for forthcoming features, than trying to
> cherry pick onto a "stable" branch. There's nothing poky's structure
> provides that can't also be provided via branching policy in the
> individual repositories.

I like what Chris said.  I vote for this.  It is standard SCM
practice.  All development goes on in a branch.  Integration on
another branch.  When good enough, it is merged to master and tagged
as a milestone release.

Regards,

Brian

Re: Moving angstrom under the yocto banner

[Darren Hart]

On 04/03/2012 10:34 AM, Brian Hutchinson wrote:
> On Tue, Apr 3, 2012 at 1:26 PM, Chris Larson <clarson@kergoth.com> wrote:
>> I really don't see what the issue is here. If you want a stable
>> branch, we can look into creating such a thing upstream, though I'm
>> personally of the opinion that master should remain release-quality,
>> and make better use of feature branches, potentially a
>> next/integration branch for forthcoming features, than trying to
>> cherry pick onto a "stable" branch. There's nothing poky's structure
>> provides that can't also be provided via branching policy in the
>> individual repositories.
> 
> I like what Chris said.  I vote for this.  It is standard SCM
> practice.  All development goes on in a branch.  Integration on
> another branch.  When good enough, it is merged to master and tagged
> as a milestone release.

I'd really like to see this as well.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Moving angstrom under the yocto banner

[Koen Kooi]

Dave,

Coud summarize the discussion about this during bspfest, collab and the AB meeting please?

regards,

Koen

Op 30 mrt. 2012, om 21:00 heeft Osier-mixon, Jeffrey het volgende geschreven:

> As I understand it - Poky is sort of a "reference distro" for the Yocto system. I think Angstrom would be an excellent addition as an alternative, and I'd be happy to do anything needed on the community side to help.
> 
> On Fri, Mar 30, 2012 at 11:44 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Hi,
> 
> RP said I should raise this on the yocto lists, so here it is:
> 
> The Angstrom core team would like to move angstrom under the yocto banner so we can formally claim to be 'yocto'.
> 
> What is the process to make that happen? I suspect OSVs will need to know as well, since lately yocto is being defined as 'poky + 1 bsp layer' which makes it impossible to provide any added value if you want to keep calling it 'yocto' to your customers.
> 
> regards,
> 
> Koen
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> -- 
> Jeff Osier-Mixon http://jefro.net/blog
> Yocto Project Community Manager @Intel http://yoctoproject.org
> 

Re: Moving angstrom under the yocto banner

[Stewart, David C]

[Note, Koen is trying to get davest to respond quickly by trying a top post. Good work, Koen!]

>From: Koen Kooi [mailto:koen@dominion.thruhere.net]
>Sent: Tuesday, April 10, 2012 7:04 AM
>
>Dave,
>
>Coud summarize the discussion about this during bspfest, collab and the AB
>meeting please?

Evidently I created a firestorm of controversy with my previous stupid questions on this topic. At the risk of doing so again, will soldier on.  Official minutes coming from Shane/Jefro in coming days.

I think we're all in agreement with the intent of the Yocto Project - to minimize or eliminate the redundant effort required currently in embedded Linux. This is why we have people slaving away to QA our release bits and fix bugs, for example. 

With that intent clear, we're still trying to work out which parts of the projects are intended to be upstreams and which are there just as examples. There is some additional clarity we need in order to make this really clear, and I think RP took the action to work on this. (Some of the lack of clarity is that there are still a lot of things called "poky" and go by fancy video game character names, which might need to change).

In the AB meeting, we spent time talking about the use of the Yocto Project (tm) logo and brand. We agreed to create a straw man spreadsheet of requirements for this and will discuss over the next month. The analogy here is to the CGL requirements form, only I'm hoping it's closer to maybe a dozen lines to fill in rather than 200. :-)

Dave

>regards,
>
>Koen
>
>Op 30 mrt. 2012, om 21:00 heeft Osier-mixon, Jeffrey het volgende
>geschreven:
>
>> As I understand it - Poky is sort of a "reference distro" for the Yocto system.
>I think Angstrom would be an excellent addition as an alternative, and I'd be
>happy to do anything needed on the community side to help.
>>
>> On Fri, Mar 30, 2012 at 11:44 AM, Koen Kooi
><koen@dominion.thruhere.net> wrote:
>> Hi,
>>
>> RP said I should raise this on the yocto lists, so here it is:
>>
>> The Angstrom core team would like to move angstrom under the yocto
>banner so we can formally claim to be 'yocto'.
>>
>> What is the process to make that happen? I suspect OSVs will need to know
>as well, since lately yocto is being defined as 'poky + 1 bsp layer' which makes
>it impossible to provide any added value if you want to keep calling it 'yocto' to
>your customers.
>
>>
>> regards,
>>
>> Koen
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> --
>> Jeff Osier-Mixon http://jefro.net/blog
>> Yocto Project Community Manager @Intel http://yoctoproject.org
>>

Re: Moving angstrom under the yocto banner

[Daniel Lazzari]

I just thought I'd chime in on this discussion as someone who is outside of both groups. It's been difficult to explain to our teams internally the whole Yocto Project vs. Angstrom-core terminology, and since everyone here is familiar with Linux and distros, we decided to put it in those terms. Note that not coming from these groups, there's a good chance we've been explaining it all wrong, in which case, feel free to correct and clarify and I'd be happy to change our internal explanations.

We see bitbake/oe-core as Debian based Linux, Poky and Angstrom as distros (like Ubuntu and Debian), and the Yocto Project as something like Canonical. The Yocto Project regularly contributes to bitbake and oe-core, but also maintains layers and products on top of that, like meta-yocto and the Eclipse ADT plugin, all of which constitutes the Poky distro. The Yocto Project then has regular releases of stable snapshots, much like you have Ubuntu 10.04, 10.10, etc.

That said, I personally feel (this is not necessarily representative of my co-workers or company) that Angstrom, as a distro, should be allowed to use the Yocto Project name and have the Yocto Project post information about Angstrom on their Projects page, if Angstrom can stick to a regular release schedule that meets the same quality requirements that Poky does. I think that would ensure that the Yocto Project trademark maintains a quality image while helping users whose projects align better with the Angstrom distro than with Poky know that there are other oe-core distros out there.

Daniel Lazzari Jr.
Firmware Engineer, LeapFrog
dlazzari@leapfrog.com