wayland-protocols scope and governance

[Simon Ser]

> >                                   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").
>
> 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.
>
> > c. The "xdg" namespace is established for protocols useful for implementing
> >    desktop-like systems.
>
> Usage in only 'desktop-like' systems is not how xdg based protocols are
> used today, so this definition is incorrect to begin with. A better
> definition might be
>
>  c. The "xdg" namespace is established for protocols letting clients
>     configure surfaces as "windows", allowing clients to affect how they
>     are managed.

Sounds like a good definition to me.

> > 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.
> > e. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by
> >    at least one member.
>
> This effectively means that any member can add any protocol under the
> "ext" namespace without any limitations. Is this really the intention
> here?

Hmm. Maybe "one other 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.
>
> I see the point of this, philosophically, but is it really a restriction
> we want? Lets pretend some proprietary compositor shows up and wants to
> collaborate developing some kind of protocol that'd fit into the "ext"
> category. Maybe there are open source clients who are interested in this
> functionality, or maybe they provide their own proprietary client; would
> we really want to keep them out instead of working together?

I do believe requiring open-source implementations is a good idea.

The goal of this requirement is to make it possible for reviewers to:

- Test that the protocol works in practice. In case the only way to test is by
  running a proprietary blob, this would put some reviewers out of the
  discussion either because of technical issues (blob not available for all
  platforms) or just because reviewers don't trust the proprietary blob.
- Check that the implementation is consistent with the spec. Testing all corner
  cases without access to the source code is very tedious.
- Understand how the implementation works, what are the limitations of the
  protocol, and uncover possible oversights. This is probably the most important
  part, and it's also a very hard thing to do without access to source code.

An open-source implementation also helps a lot ensuring that a protocol will be
successful. See https://tools.ietf.org/html/rfc5218#section-2.1.3.

> The availability of an "open source implementation" is also somewhat
> vague; does a "dummy implementation" count, or how fully featured must
> it be to be considered "good enough" for this requirement to be met?

I don't think a dummy implementation is okay. Though, I'm not sure how to phrase
this "good enough" requirement.

> >                          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.
>
> Is it really necessary with a 30 days minimum for amending existing
> protocols? For introduction of new ones, I see the point, but especially
> for non-controversial amendments (e.g. bug fixes) to unstable protocols,
> it seems a bit excessive.
>
> We could, however, maybe we should add a similar requirement for
> declaring a protocol "stable".

Agreed.

> >                        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 push their change to the
> >    wayland-protocols repository at this point.
>
> There are a few places that mentiones "pushing" to the repository. For
> changing changes to the adoption website/database it seems like a
> reasonable thing, but for protocol addition and amendments and amending
> this document, let's just use merge requests directly so that we can
> make use of CI to ensure things passes checks before reaching the master
> branch.

I think Drew used the term "push" in its broad meaning. After all when you merge
a MR GitLab will push new commits to the master branch.

I'm fine with replacing "push" with "merge".