Compliance program questions

Compliance program questions

[Nicolas Dechesne]

Hi there,

I have a couple of questions regarding the compliance program. If
there is a better place for asking such questions, please let me know.

I have studied the Yocto compliance documentation, [1] on the website,
and I have the following questions:

 - is there any 'practical' guide with "do's and don'ts" to help make
a sucessful Yocto Project Compatible registration?
 - i understand that while the project should build with the OE core
toolchain, it is not required to use the OE core toolchain 'by
default', so we should be able to provide our own modified/customized
toolchain in our layers, is my understanding correct?
 - it is recommended, but not mandatory not use the Yocto kernel, so
we can use any mainline version in our BSP layers, right?
 - is it tolerated to change the versions of some components from
OE-core or meta-oe? Not just add patches through .bbappend, but
actually use an older or a more recent version of components, let's
say Gstreamer for example?
 - can we included new recipes for software programs not already
included in oe-core or meta-oe in our layers, or do we have to
contribute them back into oe-core or meta-oe before registration?
 - the Yocto project compatible registration is made against a
specific version of Yocto. What happens when a new Yocto version is
released? Should we go through the registration process again?

thanks a lot!

nicolas


[1] https://www.yoctoproject.org/ecosystem/yocto-project-compliance-program

Re: Compliance program questions

[Jeff Osier-Mixon]

Hi Nicolas, thanks for asking these questions. We are in the process
of revising the documentation and application forms for that program,
so your questions come at a very good time.

I have a few answers:

On Thu, Apr 25, 2013 at 8:36 AM, Nicolas Dechesne <ndec13@gmail.com> wrote:
> Hi there,
>
> I have a couple of questions regarding the compliance program. If
> there is a better place for asking such questions, please let me know.
>
> I have studied the Yocto compliance documentation, [1] on the website,
> and I have the following questions:
>
>  - is there any 'practical' guide with "do's and don'ts" to help make
> a sucessful Yocto Project Compatible registration?

We don't have a guide like this, but I can create one. I'm guessing
you are looking for guidance on how to answer individual questions as
well as how one answer affects the others, is that correct?

>  - i understand that while the project should build with the OE core
> toolchain, it is not required to use the OE core toolchain 'by
> default', so we should be able to provide our own modified/customized
> toolchain in our layers, is my understanding correct?

Yes - the project needs to be able to build with the standard
toolchain, but you can provide your own as well.

>  - it is recommended, but not mandatory not use the Yocto kernel, so
> we can use any mainline version in our BSP layers, right?

I believe this is the case, but I'll need to research & get back to you.

>  - is it tolerated to change the versions of some components from
> OE-core or meta-oe? Not just add patches through .bbappend, but
> actually use an older or a more recent version of components, let's
> say Gstreamer for example?

I don't think we require specific versions of any packages, but again
I'll have to research first.

>  - can we included new recipes for software programs not already
> included in oe-core or meta-oe in our layers, or do we have to
> contribute them back into oe-core or meta-oe before registration?

Yes, you can include new recipes (and packages).

>  - the Yocto project compatible registration is made against a
> specific version of Yocto. What happens when a new Yocto version is
> released? Should we go through the registration process again?

That is a question we have discussed quite a lot. The plan of record
is for YP Compatible products/projects to resubmit the form after
testing with the new version. However, that does create a problem if
someone has, for example, a dozen YP Compatible products. Plus, what
happens with point releases? These issues are under discussion & I'll
report back as soon as I have clear answers.

> thanks a lot!

Thank you for asking these questions!

>
> nicolas
>
>
> [1] https://www.yoctoproject.org/ecosystem/yocto-project-compliance-program
> _______________________________________________
> 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: Compliance program questions

[Nicolas Dechesne]

Jeff,

On Thu, Apr 25, 2013 at 7:52 PM, Jeff Osier-Mixon <jefro@jefro.net> wrote:
> Hi Nicolas, thanks for asking these questions. We are in the process
> of revising the documentation and application forms for that program,
> so your questions come at a very good time.

thanks a lot for your quick answer, and I am glad that it's right on time!

>
> I have a few answers:
>
> On Thu, Apr 25, 2013 at 8:36 AM, Nicolas Dechesne <ndec13@gmail.com> wrote:
>> Hi there,
>>
>> I have a couple of questions regarding the compliance program. If
>> there is a better place for asking such questions, please let me know.
>>
>> I have studied the Yocto compliance documentation, [1] on the website,
>> and I have the following questions:
>>
>>  - is there any 'practical' guide with "do's and don'ts" to help make
>> a sucessful Yocto Project Compatible registration?
>
> We don't have a guide like this, but I can create one. I'm guessing
> you are looking for guidance on how to answer individual questions as
> well as how one answer affects the others, is that correct?

Yes my questions below are clearly good target for such a 'compliance' tutorial.

>
>>  - i understand that while the project should build with the OE core
>> toolchain, it is not required to use the OE core toolchain 'by
>> default', so we should be able to provide our own modified/customized
>> toolchain in our layers, is my understanding correct?
>
> Yes - the project needs to be able to build with the standard
> toolchain, but you can provide your own as well.

ok.

>
>>  - it is recommended, but not mandatory not use the Yocto kernel, so
>> we can use any mainline version in our BSP layers, right?
>
> I believe this is the case, but I'll need to research & get back to you.

at least meta-arago seems to provide a couple of kernel, so i expect
it should be ok, but worth checking.

>
>>  - is it tolerated to change the versions of some components from
>> OE-core or meta-oe? Not just add patches through .bbappend, but
>> actually use an older or a more recent version of components, let's
>> say Gstreamer for example?
>
> I don't think we require specific versions of any packages, but again
> I'll have to research first.

that question is currently the most important for me, so please let me
know. again, just to avoid any confusion, we would need to downgrade
several recipes to older versions. the idea would be to import such
recipes from OE tree history if they ever existed, or create them from
scratch, if needed.

>
>>  - can we included new recipes for software programs not already
>> included in oe-core or meta-oe in our layers, or do we have to
>> contribute them back into oe-core or meta-oe before registration?
>
> Yes, you can include new recipes (and packages).

ok.

>
>>  - the Yocto project compatible registration is made against a
>> specific version of Yocto. What happens when a new Yocto version is
>> released? Should we go through the registration process again?
>
> That is a question we have discussed quite a lot. The plan of record
> is for YP Compatible products/projects to resubmit the form after
> testing with the new version. However, that does create a problem if
> someone has, for example, a dozen YP Compatible products. Plus, what
> happens with point releases? These issues are under discussion & I'll
> report back as soon as I have clear answers.

ok, thanks again. looking forward for your next set of answers.

Re: Compliance program questions

[Nicolas Dechesne]

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

Hi there,



>
>
> Jeff,
>
> On Thu, Apr 25, 2013 at 7:52 PM, Jeff Osier-Mixon <jefro@jefro.net> wrote:
> > Hi Nicolas, thanks for asking these questions. We are in the process
> > of revising the documentation and application forms for that program,
> > so your questions come at a very good time.
>
> thanks a lot for your quick answer, and I am glad that it's right on time!
>

trying to revive this thread, and check if there is any update on the
revised documentation/forms.

Also, i have an additional question. It is not clear from the 'registration
form' whether or not a commercial project can be (or not) registered as
Yocto Project Compatible. I am talking here about a commercial project that
includes non-free s/w (isolated in proper layers) allthough:
 - all changes to oe-core, bitbake, meta-oe, ... are contributed back
 - all processes/recommendations are followed properly (distro policies
isolated, README, ...)

Can such a project be 'branded' as Yocto?

I was initially under the impression that non free (and commercial) s/w was
prohibited, but then I noticed Enea Linux which does seem to be commercial
(i don't know if it included non free, though).

Looking at the registration form again, it seems that "all" it might take
is to be a Yocto Project member.

is that correct?



>
> >
> > I have a few answers:
> >
> > On Thu, Apr 25, 2013 at 8:36 AM, Nicolas Dechesne <ndec13@gmail.com>
> wrote:
> >> Hi there,
> >>
> >> I have a couple of questions regarding the compliance program. If
> >> there is a better place for asking such questions, please let me know.
> >>
> >> I have studied the Yocto compliance documentation, [1] on the website,
> >> and I have the following questions:
> >>
> >>  - is there any 'practical' guide with "do's and don'ts" to help make
> >> a sucessful Yocto Project Compatible registration?
> >
> > We don't have a guide like this, but I can create one. I'm guessing
> > you are looking for guidance on how to answer individual questions as
> > well as how one answer affects the others, is that correct?
>
> Yes my questions below are clearly good target for such a 'compliance'
> tutorial.
>
> >
> >>  - i understand that while the project should build with the OE core
> >> toolchain, it is not required to use the OE core toolchain 'by
> >> default', so we should be able to provide our own modified/customized
> >> toolchain in our layers, is my understanding correct?
> >
> > Yes - the project needs to be able to build with the standard
> > toolchain, but you can provide your own as well.
>
> ok.
>
> >
> >>  - it is recommended, but not mandatory not use the Yocto kernel, so
> >> we can use any mainline version in our BSP layers, right?
> >
> > I believe this is the case, but I'll need to research & get back to you.
>
> at least meta-arago seems to provide a couple of kernel, so i expect
> it should be ok, but worth checking.
>
> >
> >>  - is it tolerated to change the versions of some components from
> >> OE-core or meta-oe? Not just add patches through .bbappend, but
> >> actually use an older or a more recent version of components, let's
> >> say Gstreamer for example?
> >
> > I don't think we require specific versions of any packages, but again
> > I'll have to research first.
>
> that question is currently the most important for me, so please let me
> know. again, just to avoid any confusion, we would need to downgrade
> several recipes to older versions. the idea would be to import such
> recipes from OE tree history if they ever existed, or create them from
> scratch, if needed.
>
> >
> >>  - can we included new recipes for software programs not already
> >> included in oe-core or meta-oe in our layers, or do we have to
> >> contribute them back into oe-core or meta-oe before registration?
> >
> > Yes, you can include new recipes (and packages).
>
> ok.
>
> >
> >>  - the Yocto project compatible registration is made against a
> >> specific version of Yocto. What happens when a new Yocto version is
> >> released? Should we go through the registration process again?
> >
> > That is a question we have discussed quite a lot. The plan of record
> > is for YP Compatible products/projects to resubmit the form after
> > testing with the new version. However, that does create a problem if
> > someone has, for example, a dozen YP Compatible products. Plus, what
> > happens with point releases? These issues are under discussion & I'll
> > report back as soon as I have clear answers.
>
> ok, thanks again. looking forward for your next set of answers.
>

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

Re: Compliance program questions

[Mark Hatle]

On 4/25/13 10:36 AM, Nicolas Dechesne wrote:
> Hi there,
>
> I have a couple of questions regarding the compliance program. If
> there is a better place for asking such questions, please let me know.
>
> I have studied the Yocto compliance documentation, [1] on the website,
> and I have the following questions:

Below are my opinions, but I've been working on compliance issues for a while on 
our products.

>   - is there any 'practical' guide with "do's and don'ts" to help make
> a sucessful Yocto Project Compatible registration?

There probably should be.  I see Jeffro has already responded about this.

>   - i understand that while the project should build with the OE core
> toolchain, it is not required to use the OE core toolchain 'by
> default', so we should be able to provide our own modified/customized
> toolchain in our layers, is my understanding correct?

The intention is that you aren't doing anything that will make it difficult to 
work with the oe-core toolchain.  But we understand that new architectures may 
require a custom toolchain.  Also custom toolchains may be provided by the 
vendor for optimization and other reasons.  When I do my testing my rule is, 
everything must build with the oe-core toolchain, unless it's not implemented or 
has the same bug in the community.  (Not implemented is the case where an 
optimization or architecture doesn't existing in oe-core.)

>   - it is recommended, but not mandatory not use the Yocto kernel, so
> we can use any mainline version in our BSP layers, right?

You can, but I've been told this is in the process of being revised.  The reason 
for using the Yocto Project kernel is that it provides a common foundation for 
YP participants.  This common foundation should allow people familiar with the 
kernel tooling to make better use of the kernel sources and do things in a more 
reusable way.  It's only recommended currently because it's clear that the 
overall embedded community was not ready to embrace the tooling and versions 
selected by the Yocto Project at the time the guidelines were written.

>   - is it tolerated to change the versions of some components from
> OE-core or meta-oe? Not just add patches through .bbappend, but
> actually use an older or a more recent version of components, let's
> say Gstreamer for example?

If you change an upstream repository, oe-core, meta-oe, meta-yocto, etc.. You 
should submit the patch to the appropriate upstream.  If the 'change' has been 
backported from a newer version then it's already been submitted upstream. 
(Good process here is to document the commit ID of what you backported, so it's 
easy to show compliance.)

This holds true on .bbappends and new versions of things.  Note: if you put your 
new version of the code in your own custom layer, you don't need to submit it 
upstream for compliance.  (But I recommend you do as it will make long term 
maintenance much easier!)

>   - can we included new recipes for software programs not already
> included in oe-core or meta-oe in our layers, or do we have to
> contribute them back into oe-core or meta-oe before registration?

Your layers are your own responsibility.  There is nothing that forces you to 
provide anything in your layer to an upstream location.  You just have to verify 
that it works with a suitable version of oe-core.

The contribution requirement is geared toward people who repackage oe-core and 
other open source layers for their customers.  It will help ensure that someone 
isn't hiding or playing games with their local version of oe-core to make it 
incompatible with other versions.  (Sure they can do that, but whatever they did 
to make it incompatible will have at least been sent to the public.)

>   - the Yocto project compatible registration is made against a
> specific version of Yocto. What happens when a new Yocto version is
> released? Should we go through the registration process again?

Yes.  The registration process will have to be repeated.

--Mark

>
> thanks a lot!
>
> nicolas
>
>
> [1] https://www.yoctoproject.org/ecosystem/yocto-project-compliance-program
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Compliance program questions

[Nicolas Dechesne]

On Fri, Apr 26, 2013 at 12:28 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>   - is it tolerated to change the versions of some components from
>> OE-core or meta-oe? Not just add patches through .bbappend, but
>> actually use an older or a more recent version of components, let's
>> say Gstreamer for example?
>
>
> If you change an upstream repository, oe-core, meta-oe, meta-yocto, etc..
> You should submit the patch to the appropriate upstream.  If the 'change'
> has been backported from a newer version then it's already been submitted
> upstream. (Good process here is to document the commit ID of what you
> backported, so it's easy to show compliance.)
>
> This holds true on .bbappends and new versions of things.  Note: if you put
> your new version of the code in your own custom layer, you don't need to
> submit it upstream for compliance.  (But I recommend you do as it will make
> long term maintenance much easier!)


I don't think i will change 'upstream' repo, in fact i don't even
think we will redistribute (copy) the upstream oe-core and meta-oe.
but we will need to use older version of some components (and perhaps
newer version too sometimes). so I was planning to add the recipes for
the older versions of an existing component into our 'distro' or
'extras' layers.

as for .bbappend, i think we will only use bbappend to add non generic
patches and/or alter the build configure options, none of that would
need to be upstream, i guess.

and, yes i understand that if in that process we happen to package new
components, we will try to 'upstream' them in oe-core or meta-oe, for
sure.