On Thu, Sep 05, 2019 at 09:34:59PM +, Simon Ser wrote:
> This is v3 of the proposal.
>
> Changes from v2 to v3:
> - Use Jonas' definition of the "xdg" namespace (Jonas)
> - Amendments to existing protocols require no minimum discussion period
> (Jonas)
> - Specify the requirements for declaring a protocol stable (Jonas)
>
> Diff: https://sr.ht/lIEx.patch
>
> I'm not sure what you mean by this, Jonas:
>
> > The usage of a dash instead of underscore is what the name as well as
> > file name should use. The underscore is for protocol interface, requests and
> > events only.
>
> The current proposal already specifies this, what am I missing?
Can't remember what I was referring to, but it looks correct in this
version.
>
> Re: open-source server & client implementation: should we add a
> requirement that maintainers ack the implementation? (Just like kernel
> uAPI changes require)
Not sure about this one. An implementation could very well be a thin
wrapper around more complex infrastructure that would take a large
effort to understand for someone not familiar with the code base.
>
> * * *
>
> wayland-protocols governance
>
> This document governs the maintenance of wayland-protocols and serves to
> outline
> the broader process for standardization of protocol extensions in the Wayland
> ecosystem.
>
> 1. Membership
>
> Membership in wayland-protocols is offered to stakeholders in the Wayland
> ecosystem who have an interest in participating in protocol extension
> standardization.
>
> 1.1. Membership requirements
>
> a. Membership is extended to projects, rather than individuals.
> b. Members represent general-purpose projects with a stake in multiple Wayland
>protocols (e.g. compositors, GUI toolkits, etc), rather than
> special-purpose
>applications with a stake in only one or two.
> c. Each project must provide one or two named individuals as points-of-contact
>for that project who can be reached to discuss protocol-related matters.
>
> 1.2. Becoming a member
>
> a. New members who meet the criteria outlined in 1.1 are established by
>invitation from an existing member. Projects hoping to join should reach
> out
>to an existing member asking for this invitation.
> b. New members shall write to the wayland-devel mailing list stating their
>intention of joining and their sponsor.
> c. The sponsor shall respond acknowledging their sponsorship of the
> membership.
> d. A 14 day discussion period for comments from wayland-protocols members will
>be held.
> e. At the conclusion of the discussion period, the new membership is
> established
>unless their application was NACKed by a 1/2 majority of existing members.
>
> 1.3. Ceasing membership
>
> a. A member may step down by writing their intention to do so to the
>wayland-devel mailing list.
> b. A removal vote may be called for by an existing member by posting to the
>wayland-devel mailing list. This begins a 14 day voting & discussion
>period.
> c. At the conclusion of the voting period, the member is removed if the votes
>total 2/3rds of members.
> d. Removed members are not eligible to apply for membership again for a period
>of 1 year.
> e. Following a failed vote, the member who called for the vote cannot
>call for a re-vote or propose any other removal for 90 days.
>
> 2. Protocols
>
> 2.1. Protocol namespaces
>
> a. Namespaces are implemented in practice by prefixing each interface name in
> a
>protocol definition (XML) with the namespace name, and an underscore (e.g.
>"xdg_wm_base").
> b. Protocols in a namespace may optionally use the namespace followed by a
> dash
>in the name (e.g. "xdg-shell").
> c. The "xdg" namespace is established for protocols letting clients
>configure its surfaces as "windows", allowing clients to affect how they
>are managed.
> d. The "wp" namespace is established for protocols generally useful to Wayland
>implementations (i.e. "plumbing" protocols).
> e. The "ext" namespace is established as a general catch-all for protocols
> that
>fit into no other namespace.
>
> 2.2. Protocol inclusion requirements
>
> a. All protocols found in the "xdg" and "wp" namespaces at the time of writing
>are grandfathered into their respective namespace without further
> discussion.
> b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only
> if
>ACKed by at least 3 members.
> c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if
>if NACKed by any member.
> d. Protocols in the "xdg" and "wp" namespaces must have at least one
> open-source
>client implementation & two open-source server implementations to be
> eligible
>for inclusion.
