wayland-protocols scope and governance

[Jonas Ådahl]

On Tue, Jun 18, 2019 at 07:31:47PM -0400, Drew DeVault wrote:
> On Mon Jun 17, 2019 at 9:55 AM Jonas Ådahl wrote:
> > > 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.
> 
> ACK
> 
> > > 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.
> 
> I'm okay with this definition, but I'll again mention that this wording
> makes a clear case for the wlr toplevel management protocol:
> 
> https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml
> 
> This is your chance to object to a wording that would include this
> protocol.

s/configure surfaces/configure its surfaces/ would rule out accidentally
including external window manager like protocols into the xdg namespace.

> 
> > > 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?
> 
> Yep.
> 
> > > 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?
> 
> If the open source clients are interested in this functionality, they
> can implement it before it's standardized in wayland-protocols. This is
> already how most protocols are developed today. Nothing stops us from
> collaborating on protocols which don't yet meet the requirements for
> inclusion in wayland-protocols.
> 
> > 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 think we ought to use our best judgement here, erring on the side of
> "it counts" and making our arguments if we think an implementation does
> not.
> 
> > >                          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.
> 
> Open to rewording this to:
> 
> 	e. Amendments to existing protocols may be proposed by the same
>        process, with no minimum discussion period.

Sounds reasonable to me.

> 
> > We could, however, maybe we should add a similar requirement for
> > declaring a protocol "stable".
> 
> ACK
> 
> > >                            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.
> 
> Merge requests are already used for protocol additions, protocol
> amendments, and amendments to this document, per sections 2.3.a and 4.a.
> Did I miss something?

It's the choice of words here, as "push" is something you do to bypass a
"merge" action done via Gitlab. "Merge" would be better, as it doesn't
imply anyone should call "git push" anywhere.


Jonas