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

[akuster]

Jeffery,

Sounds good to me.

- Armin

-----Original Message-----
From: "Osier-mixon, Jeffrey" <jeffrey.osier-mixon at intel.com>
To: akuster at mvista <akuster at mvista.com>
Cc: yocto-ab at yoctoproject.org <yocto-ab at yoctoproject.org>
Subject: Re: [yocto-ab] YP Advisory Board: YP Compatible changes
Date: Thu, 12 Jun 2014 14:51:48 -0700

I'm reviving this discussion, as I don't want it to stall out completely.

Please read this all the way through. If we can't resolve this by
email, I may call a special meeting of the Advisory Board so we can
move forward. TLDR summaries are at the top of each section.
________________________________________________

First: YP Compatible and Participant are branding programs.

I want to remind everyone about the difference between a layer that is
"compatible" - i.e. one that has technical compatibility with the
project - and one that meets the criteria of our YP Compatible
program.

YP Compatible and YP Participant are co-branding programs, not true
compliance programs. Otherwise, layers, products, or organizations
would qualify solely on meeting specific criteria, and there would be
no need for a vote.

In addition, products can be designated YP Compatible if they are
built with YP Compatible parts, pass RP's sniff test, and are voted in
by the Advisory Board. Same goes for private layers.

The Advisory Board can grant it to anything they want if they can
convince RP that that thing deserves it. Many items that are quite
compatible with the project do not qualify for YP Compatible status
because their sponsoring orgs are not YP members (or open source
projects).

To reiterate - YP Compatible is about branding, period. It is not a
spec, and you can't conform to it or comply with it.

If any of this is unclear, please bring it up for discussion now.

I would like to immediately change the name on the website from
"Compliance Program" to "Collaborative Branding Program" in the hope
that we can partly alleviate this misconception.

In the future, I also believe we should change the name of YP
Compatible to some other adjective, but that is for a different
discussion. Let's get through redefining the program first.

________________________________________________

Second - our current system requires too much of RP's time and too
much Advisory Board time on meaningless votes.

Right now, all YP Compatible items require new votes whenever they are
superseded, or whenever YP is released. Richard's technical
organization is required to weigh in every time, and the Advisory
Board is required to vote on every change.

As an example, let's say YP member organization Acme Sillycon has a
BSP layer called meta-acme that they have submitted for YP Compatible.
They are a member org and RP approves of their layer, so the board
votes yes (of course) and they get YP Compatible status for YP 1.10.

Under the current system, every time there is a meta-acme release OR a
YP release, they need to reapply and the Advisory Board needs to vote.
If the layer is released twice a year and YP is released twice a year,
that is 4 Advisory Board votes per year for this one item.

Now imagine that Acme has a dozen layers that all need this kind of
attention. And imagine that there are 20 organizations in the project
with similar needs. The Advisory Board would do little other than cast
votes.

These are the "rubber stamp" votes that very often come up after a
release. These votes are a pointless waste of time, especially when
anyone can complain if they see something amiss. In the program's
existence since 2012, no one has ever voted against YP Compatible
status for a layer or product that had that status in the past, and no
one has ever complained about any other member organization.

If we were a consortium or some other organization with overflowing
funds and a thirst for bureaucracy, we could hire someone to create a
spec and then police everyone to follow that spec. We do not have
anything remotely like those kinds of resources, particularly not for
a branding program.

We are an open source project based on mutual trust, consensus, and
shared resources that add tremendous value to every one of our
organizations, not just a few, and we use our limited funds to
everyone's benefit. Sharing the load makes us all stronger.

________________________________________________

Third - here are the three goals for the proposed change, and the new
rules that comprise the change.

I have tried to summarize the proposed new rules for YP Compatible.
There are three main goals with these changes:

- to minimize the "rubber-stamp" Advisory Board votes required for each release

- to offload from the technical team the responsibility for verifying
each new release

- to empower the sponsoring organizations with the responsibility for
maintaining their own branding while keeping overall control with RP
and the Advisory Board

To summarize the changes:

0 - I will work with RP to create specific guidelines for member orgs
to follow regarding what can be considered YP Compatible and what
can't. I will also work on the existing messaging to clarify the
program better.

1 - Going forward, layers or products 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. YP Compatible items from
non-member orgs will keep the existing rules.

2 - Every time YP or the item itself is released, the sponsoring org
must fill out a form verifying that the YP Compatible item still meets
the guidelines.

3 - If anyone complains that a product or layer does not meet the
guidelines, RP's organization and I will investigate and recommend
changes or remove it from the list. It is incumbent on the sponsoring
organization to fix any problems that arise.

One potential addition to these rules is to revisit all layers
periodically, e.g. annually or by some other measure. That would
negate many of the benefits that these changes are designed to effect,
though, and I do not recommend it.

As an aside, I have added a line to each program's questionnaire about
making sure they have layers listed in the OE layer index, in
accordance with RP's wishes. I have also added instructions to the
effect that each applicant should let us know how they are using the
project and how they are visibly participating.

________________________________________________

I could set up a vote to authorize these changes, but I would rather
hear from everyone before moving forward. Consensus-based
decision-making is one of the strengths of the project, so if you have
specific changes you would like to make or concerns you don't feel are
being addressed, please bring them up and follow through on the
discussion so we can get to the next step.


More comments inline below:


On Sun, Jun 1, 2014 at 8:29 PM, akuster at mvista <akuster at mvista.com> wrote:
>
> 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.

I think this applies directly to the explanation above that YP
Compatible is a branding program, not a measure of what works with YP.
The reason meta-selinux etc. are not listed is because their
maintainers have not submitted the form to make them so, probably
because branding is not required for them.

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

This is a very interesting and important point, and I think it bears
repeating - the repo has nothing to do with the branding program.

"Compliance" is a term which has no real meaning in YP. Whether a
layer is listed in the YP git repo, the layer index, or even our
downloads page has no bearing on whether the owners of that layer can
use YP branding assets. Those are completely separate issues.

The only measure of what has YP Compatible status, and can use that
status in marketing activities, is the registrar
(https://www.yoctoproject.org/ecosystem/compliance-program-registrar).

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

Whether a layer or product is public has no bearing on YP Compatible.
RP is the final arbiter on the technical side.

On the business side, only YP member organizations and open-source
projects (like Angstrom) qualify for this branding program currently.
We have discussed many times opening it up to non-members, but the
desire has always been expressed that this program brings value to YP
membership, so we have kept it as it is.

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

This automated system would only work for things that go through this
particular process. Private layers, products, etc. would have a
different process. The point of this process is that the sponsoring
organization needs to track whether they are YP Compatible, as the
project itself does not have the resources to do this.

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

RP can make that a requirement, and I think it would be a good
decision. In my opinion, every layer should have a maintainer listed
in a README or MAINTAINERS file.

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

I don't think it makes a difference whether a layer is private or
public, but it would be interesting to discuss the difference. Keep in
mind, though, that the point of this change is to put responsibility
on the sponsoring organization for maintaining their YP Compatible
status.

thanks all