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

[Osier-mixon, Jeffrey]

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. 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. 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.

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.

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.

thanks for any input
-- 
Jeff Osier-Mixon @Intel
Yocto Project Community Manager http://yoctoproject.org