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

[William Mills]

[oops, I found this on my desktop today.
I thought I hit send yesterday.]

On 06/16/2014 05:01 PM, Osier-mixon, Jeffrey wrote:
>> It has been suggested that I spell out what I would like to see.
>> I did this a bit in the call the other day but it is unreasonable of me to
>> expect anyone to remember that.  The following is more detailed
>> anyway.
>
> Thanks, Bill. Unfortunately we rarely get a quorum at meetings these
> days, so many people missed the discussion. I appreciate the work you
> did to write this up.
>
> My comments below.
>
>> I would like to see something like this:
>
> I have to LOL, because this looks more draconian than what I put
> together earlier!  :)
>

Well I was trying to push it as far as I was comfortable.
I know others had expressed interest in more exacting rules so this
represents the *maximum* I am comfortable with.

>> 1) Yocto Project Compatibility will continue to be per Yocto Project
>> release, even when originations are self certifying.
>
> Yes, that aspect of the program was not intended to change
>

Good, that was not clear to me.

>> 2) Anyone can raise a compatibility concern.  (bugs.yoctoproject.org?)
>> The layer owner should be included on the problem report.  The
>> architecture team, lead by Richard, has sole responsibility to decide
>> if the issue is one that requires this process to be followed.
>
> Seems reasonable
>
>> 3) Any issue verified by the architecture team needs to be fixed before YP
>> Compatible is claimed for the project release on a later YP release.
>>
>> If an issue if found in MyOS 45 based on YP 1.7, then it needs to be fixed
>> before MyOS based on YP 1.8 can be claimed to be YP compatible.
>
> ...or MyOS 46?
>

I thought of that also but then we need to define Major version # vs 
Minor version # etc.  The YP base is easier to define.
If others want to add the "next major version of the product" I am OK 
with that.


>> 4) It is highly desirable (required?) to fix or document as a compatibility
>> errata for the current release.
>
> I'd say that would be determined by RP, and depends on how large a
> problem it actually is. That being said, it seems to me that
> documentation and/or a patch is a very reasonable way to resolve a
> current problem. As you said earlier, we really don't want to mandate
> anything in a branding program that might break things for existing
> users, and we don't want to screw the submitting organization either.
>

I think it is very important that the organization publishing the 
product remain the owner of the resolution.  Suggestions from RP are
always welcome.


>> MyOS 45.1 should include a fix if it won't hurt users of MyOS.
>> If the fix is too disruptive it should be included as an errata notice
>> in someway.  Suggested workarounds should be supplied when practicle. Choice
>> of resolution is left to the layer owner.
>>
>> Timeframe?
>>     Commercially reasonable
>>     as soon as reasonable but not to exceed 6 months
>>     etc.
>>
>> 5) It is expected that all YP members follow these rules in good faith and
>> no branding rights will ever need to be revoked once granted.  If the
>> need does arise, branding rights can be stripped from an organization
>> or project by a 2/3 majority vote of all current YP members (silver ==
>> 1 vote, gold == 2 votes).  If branding has been revoked, the
>> organization or project can reapply for branding and it will be granted
>> provided all issues have been resolved.
>
> I would be very concerned about revoking branding rights from any
> member organization, or in using or altering the Advisory Board's
> voting system to do so. I can see the value in defining the power of
> the Board in this way, but we do have to remember that all members act
> in good faith, and that for the past 3 years we have done so to a very
> high functioning level. The Board currently has this ability based on
> a simple majority, or at least that is my understanding of the current
> rules.
>

Again, this is a maximum I was comfortable with.  Tame it down all you
want.

I just wanted a very defined and formal mechanism would be the only way 
to loose branding.  And not centered on one individual, no matter how
great a person.  People do move on.

The way it was written before it sounded like it took a lot less to
"come off the list".

Yes, I knew you would not like the vote change but I wrote it anyway :)

> I would maybe add a statement that revoking these rights does not
> affect existing YP Compatible status, and that this only revokes the
> organization's right to assign YP Compatible to its own products. In
> essence, it downgrades them back to our current system, where every
> status must be voted in by the board. It does not remove their ability
> to put that status on new layers/products/releases, or affect their
> printed material for existing releases.
>
> I would very much like to hear others weigh in on this.
>
>> ********
>>
>> What this does:
>> * Put the focus for fixes on future work
>> * Focus for current work is knowledge of the issue
>> * Ensures one picky person can not torpedo a ton of marketing work or
>> invalidate physical material
>> * Allows an intentional bad actor to loose branding
>
> I think we can work with these concepts.  I'll try to summarize in the
> working draft rules below.
>
> _____________________________________________
>
> I have snipped most of the message below and kept just the proposal,
> editing to fit Bill's ideas.
>
> Goals:
>
>>>>>> - 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
>
> add:
>
> - to empower RP and/or the Advisory Board to cope with bad actors or
> others not acting in good faith, where good faith here is defined as
> "acting in the best interest of both the group and the individual" -
> specifically, retroactive punishment will not be allowed, and the
> needs of the users come first
>
> - to focus on current and future work in order to better align layers
> and products with the precepts of the project
>
>>>>>> 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.
>
> change #3 as follows, summarizing Bill's ideas above:
>
> 3 - If anyone complains that a product or layer does not meet the
> guidelines, RP's organization will investigate and work with the
> sponsoring organization to recommend changes for future versions, and
> to potentially publish errata or patches for the existing version.
>
> potentially add something like this:
>
> 4 - The Advisory Board can revoke a member's right to assign its own
> YP Compatible branding with a 2/3 majority. Existing YP Compatible
> layers/products are not affected, but the organization must then apply
> for an Advisory Board vote for any new layers, products, or releases
> until their assignation rights are reestablished by RP's advice and by
> the Advisory Board with a 2/3 majority. This is intended only to
> address repeat bad actors for the good of the project.
>
> Bill, does that address the issues you are concerned about?
>

Yes.

I am even fine if the "changes for future versions" are
requirements not suggestions as long as "future" is defined as above.

> I have no doubt that we will continue to find issues that are either
> undefined or ill defined, and we will have to work those out in good
> faith. The organizations on the project may not all be business
> partners, but we all benefit directly from refining these ideas and
> rules for the greater good of the project.
>
> <snip>
>
>> I am actually very encouraged that we are moving toward a system where we
>> all get more compatible as we learn from each other best practices for our
>> layers and our QA checks.
>
> If the YP Compatible program is able to help accomplish better
> alignment, it will be achieving its highest aspirations.
>
>