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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
