wayland-protocols scope and governance
Pekka Paalanen
ppaalanen at gmail.com
Thu Oct 10 14:29:43 UTC 2019
On Thu, 10 Oct 2019 00:21:43 +0000
Simon Ser <contact at emersion.fr> wrote:
> This is v4 of the proposal.
>
> Changes from v3 to v4: relax implementation requirements for inclusion
> in "xdg" and "wp" (Jonas, Drew).
>
> Diff: https://sr.ht/yw0R.txt
>
> * * *
>
> 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 last 3 open-source
> implementations (either 1 client + 2 servers, or 2 clients + 1 server) to be
> eligible for inclusion.
> e. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by
> at least one member.
> f. Protocols in the "ext" namespace must have at least one open-source client &
> one open-source server implementation to be eligible for inclusion.
>
> 2.3. Introducing new protocols
>
> a. A new protocol may be proposed by submitting a merge request to the
> wayland-protocols Gitlab repository.
> b. Protocol proposal posts must include justification for their inclusion in
> their namespace per the requirements outlined in section 2.2.
> c. An indefinite discussion period for comments from wayland-protocols members
> will be held, with a minimum duration of 30 days. Protocols which require a
> certain level of implementation status, ACKs from members, and so on, should
> use this time to acquire them.
> d. When the proposed protocol meets all requirements for inclusion per section
> 2.2, and the minimum discussion period has elapsed, the sponsoring member may
> push their changes to the wayland-protocol repository.
> e. Amendments to existing protocols may be proposed by the same process, with
> no minimum discussion period.
> f. Declaring a protocol stable may be proposed by the same process, with the
> regular 30 day minimum discussion period.
>
> 3. Protocol adoption documentation
>
> 3.1. Adoption website
>
> a. This section is informational.
> b. A website will be made available for interested parties to browse the
> implementation status of protocols included in wayland-protocols.
> c. A statement from each member of wayland-protocols will be included on the
> site.
> d. Each protocol will be listed along with its approval status from each member.
> e. The approval statuses are:
> 1. NACK, or "negative acknowledgement", meaning that the member is opposed to
> the protocol in principle.
> 2. NOPP, or "no opposition", meaning that the member is not opposed to the
> protocol in principle, but does not provide an implementation.
> 3. ACK, or "acknowledged", meaning that the member supports the protocol in
> principle, but does not provide an implementation.
> 4. IMPL, or "implemented", meaning that the member supports the protocol and
> provides an implementation.
> f. Each member may write a short statement expanding on the rationale for their
> approval status, which will be included on the site.
> g. A supplementary list of implementations will also be provided on the site,
> which may include implementations supported by non-members.
>
> 3.2. Changes to the adoption website
>
> a. This section is informational.
> b. A new protocol is added to the website by the sponsoring member at the
> conclusion of the discussion period (section 2.3.c).
> c. During the discussion period (section 2.3.c), interested parties may express
> their approval status on the Gitlab merge request. The default approval
> status for members who do not participate in the discussion is "NOPP".
> d. Members may change their acknowledgement status or support statement at any
> time after the discussion period (section 2.3.c) has closed by simply pushing
> their update to the wayland-protocols repository.
>
> 4. Amending this document
>
> a. An amendment to this document may be proposed any member by
> submitting a merge request on Gitlab.
> b. A 30 day discussion period for comments from wayland-protocols members will
> be held.
> c. At the conclusion of the discussion period, an amendment will become
> effective if it's ACKed by at least 2/3rds of wayland-protocols members, and
> NACKed by none. The sponsoring member may merge their change to the
> wayland-protocols repository at this point.
>
Hi,
this looks good to me too.
Acked-by: Pekka Paalanen <pekka.paalanen at collabora.com>
Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20191010/0d5cbbdd/attachment.sig>
More information about the wayland-devel
mailing list