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

[Maupin, Chase]

I personally am in favor of this and thank you Jeffro for writing it up so nicely :)

Sincerely,
Chase Maupin
Integration Team Manager
Linux Core Product Development
e-mail: chase.maupin at ti.com
phone: (214) 567-2950

For support:
Forums - http://e2e.ti.com
Wiki - http://processors.wiki.ti.com/index.php/Main_Page


>-----Original Message-----
>From: yocto-ab-bounces at yoctoproject.org [mailto:yocto-ab-
>bounces at yoctoproject.org] On Behalf Of Osier-mixon, Jeffrey
>Sent: Thursday, June 12, 2014 4:52 PM
>To: akuster at mvista
>Cc: yocto-ab at yoctoproject.org
>Subject: Re: [yocto-ab] YP Advisory Board: YP Compatible changes
>
>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
>--
>Jeff Osier-Mixon @Intel
>Yocto Project Community Manager http://yoctoproject.org
>--
>_______________________________________________
>yocto-ab mailing list
>yocto-ab at yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto-ab