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