wayland-protocols scope and governance

Fri Sep 6 07:45:21 UTC 2019

On Thu, Sep 05, 2019 at 09:34:59PM +0000, 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.

Maybe this was discussed in the past, but why two? If we'd travel back
in time, it'd stall the introduction of xdg-foreign (took quite a while
for a second server implementation to show up), which falls within the
xdg namespace scope, and it'd block addition of protocols only
interesting to a single compositor but multiple clients/toolkits (e.g.
something very tiling specific that maybe only wlroots would care about,
or something currently in gtk-shell that may be relevant for GNOME
Shell, gtk and Qt, but not for other compositors).

Same for protocols like the tablet interface; I think it's too much of a
requirement to require the protocol author to provide TWO
implementations for such a protocol, and relying on others to implement
your protocol in their own compositors is quite a lot to ask IMHO. The
end result is more likely we end up with more things like
`gtk_primary_selection` instead of going upstream first.

Jonas

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