[yocto-ab] YP Advisory Board: YP Compatible changes

[akuster@mvista]

On 05/29/2014 04:58 PM, Osier-mixon, Jeffrey wrote:
> This proposal is provided in preparation for discussion at Monday's
> Advisory Board meeting.
>
> I have put some thinking in on YP Compatible, as it really needs to be
> streamlined and better clarified, and we need to avoid the potential
> for many dozens of new, pointless votes. I think we can do both with a
> couple of minimal changes to the process.
>
> As only one example, one of our member organizations wants to create
> many distros based on their BSP layer. These distros will come from
> from several business units, and they want them all to have YP
> Compatible status since they are building with components that are
> already listed as YP Compatible.

How do I know which meta-layers are compatible? The web site does not 
list many meta layers as being compatible like meta-selinux or 
meta-cloud-services. It seems to me if a layer has been included in the 
Yocto repo, it implies compliance.  If that layer has been branched to a 
supported version, then it is compatible for that version.

> However, if we need to vote on all of
> them plus re-vote whenever either the distro or YP bumps versions,
> we'll have several dozen pointless votes every year to rubber-stamp
> these things.
>
> There are several organizations in a similar predicament, and with new
> orgs joining YP all the time, we don't want to have to accommodate
> dozens or hundreds of votes each year. I'm not even getting into the
> issues in which one of the core maintainers has to examine the
> layer/product in question and provide guidance.
Just for clarification, are requesters supposed to include their layer 
or make then public?

> And in truth, the
> Advisory Board has yet to deny a YP Compatible application from a
> member organization.
>
> I'd like to propose some small process changes to make most of these
> votes go away. In addition, we can use this new process to
> automatically post new releases to the Downloads page on the YP
> website, which is being overhauled in June.
>
> These new rules are for member organizations only. Open source
> projects still need full votes as they do currently.
>
> New rules for member orgs vis a vis YP Compatible status:
>
> 1 - BSP or feature layers from member organizations only need to be
> voted in once. After that, the
> onus is on the sponsoring organization to make sure the layer stays
> within the guidelines of the project.
>
> 2 - Every time the YP version changes, or the layer or project version
> changes, the sponsoring org has to let me know (by filling out a form)
> so the website can stay current. A special form will be created for
> this purpose. This will have to be part of the release process, and
> for layers we can also make this an automated way to add items to the
> Downloads page on the website.
This seems to imply a public layer.
>
> 3 - If anyone complains about a layer/product being out of spec, the
> sponsoring org has to respond within a few days and either propose a
> fix or prove that the reporter is wrong.
> If neither of those things
> happens, the layer/product comes off the list. It can go back on the
> list, on probation, if the owner works it out with Richard's technical
> organization, but not before.
>
> This gives member orgs full responsibility for their own layers and
> products unless someone complains, but still provides a process for
> oversight by the YP technical team. I want to keep it as simple, and
> as empowering, as possible. This covers all of the contingencies I can
> think of, but I'd be grateful if anyone can spot anything I left out.
How would a user of a layer know to whom to complain to? is this 
something that will be required in the README?
>
> Once these rules are ratified, I will write up a specific document for
> all layer maintainers to use that will cover the release and YP
> Compatible process.

My 2 cents.

  It seems to me there may be two paths for Yocto Compatible. If a layer 
resides in the Yocto repo or at some other public viewing area, it 
qualifies for automatic compatible renewal once approved . A private 
layer might required approval every time.

MV is going through this process currently. You don't know Me, MV nor 
have you seen our product/layer to make a decision. Its all about trust. 
That seems like a harder method of approving someone.

well those are my ramblings for now.

kind regards,
Armin