<div dir="ltr">Hi there,<div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
<br>
<br>
Jeff,<br>
<br>
On Thu, Apr 25, 2013 at 7:52 PM, Jeff Osier-Mixon <<a href="mailto:jefro@jefro.net">jefro@jefro.net</a>> wrote:<br>
> Hi Nicolas, thanks for asking these questions. We are in the process<br>
> of revising the documentation and application forms for that program,<br>
> so your questions come at a very good time.<br>
<br>
thanks a lot for your quick answer, and I am glad that it's right on time!<br></blockquote><div><br></div><div>trying to revive this thread, and check if there is any update on the revised documentation/forms.</div><div>

<br></div><div style>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: </div>

<div style> - all changes to oe-core, bitbake, meta-oe, ... are contributed back</div><div style> - all processes/recommendations are followed properly (distro policies isolated, README, ...)</div><div style><br></div><div style>

Can such a project be 'branded' as Yocto? </div><div style><br></div><div style>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).</div>

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