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

[Osier-mixon, Jeffrey]

The Advisory Board never actually closed or voted on the new YP Compatible
issues. I'd like for us to bring up any final thoughts by email and then
discuss and vote at tomorrow's Advisory Board meeting.

thanks

On Tue, Jun 17, 2014 at 11:14 AM, William Mills <wmills at ti.com> wrote:

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


-- 
Jeff Osier-Mixon @Intel
Yocto Project Community Manager http://yoctoproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto-ab/attachments/20140818/fafd3c20/attachment.html>