Hi, I'd like to start a discussion on the state of how development of Wayland interfaces are done and how they should be done, though less about the technical aspect of it.
Right now, the way to get a protocol officially declared stable is, more or less, to implement it in weston, wait for a while maybe making changes, and then when agreed upon moved to the wayland repository. While being in weston, the corresponding .xml file may have been copied to some other repository for being implemented elsewhere (as it should be). So far I only know of one protocol that has gone through all the steps (wl_subcompositor), the rest are still in weston or in the mailing list. Private protocols (for example gtk_shell) go through their own procedures and I don't intend cover such protocols here. I'm also don't intend to cover the desktop shell protocol core development that has been brought up before[0] because it has other requirements, such as the fact that without a shell protocol, a client cannot really do anything. Future generic extensions to a stable xdg_shell are relevant here though. A problem with the procedures we have is that it may be very hard to get any protocols past the first step (posting to the mailing list), making experimental adaptation harder, because the lack of versioning and the fact that one would need to make a guess at what mailing list post is the correct one at the moment. The reason for this I would say is unclear requirements and expectations on what an unstable/experimental protocol is, as well as unclear responsibilities on what group of people are considered gate keepers of protocols. In some cases, it may be more or less harmless to take a pending experimental protocol and release it as an experimental feature. We (GNOME) did this with pointer gestures, adding the latest version to mutter and GTK+ in order to provide it as an experimental feature. The problematic thing being that since, even though it is a generic protocol, it does not have an "official" protocol version released anywhere even though it is in use in a software release. While I believe it was pretty harmless this time, I don't think this is a generally good way to do things. For private protocols, within a private namespace, it is of course the proper way to do it, but otherwise less so. So, how can we improve these procedures? We could introduce a wayland-protocols that contains future stable protocols as well as staging / experimental protocols, while only installing stable ones. Weston, mutter, GTK+, kwin, etc would depend on it, but for experimental protocols the .xml files would still need to be copied, because otherwise one would have to depend on a specific release since experimental protocols are not necessarily backward compatibility. This would allow us to release protocols without having to wait for a wayland/weston release cycle, and we wouldn't need to wait for an actual implementation in weston to get a central point to keep track of protocols in development. It could just as well be split into the wayland or weston repositories just as it is now if the intention is to have the same release schedule. The main issue, I believe, is that we lack defined procedure and agreed upon requirements for what may actually be placed in such a repository. I don't think it makes sense to have a sandbox protocol repository for things like this; I think we need some system similar to what we have with required review and discussion, and initial iterations and releases, but I believe the pace of letting experimental protocols in and be tracked not only on a mailing list, with proper versioning etc, is too slow right now, and somehow we need to fix that. Do we need more people who should be considered gate keepers? Right now, as far as I understand it, Pekka and Daniel are the ones who currently are the de-facto gate keepers of actual protocol changes / additions, but given how things look, should we consider defining some requirements for releasing experimental / staging protocol versions, such as R-B's by at least N out of a set of persons, and expanding this set of persons to a few more? (Note that I'm not blaming anyone for taking time etc, I completely understand the lack of time available to spend on reviewing protocols and protocol implementations). For declaring a protocol stable there should of course be stricter requirements than for experimental ones, but also here we need to reconsider how we should do things differently regarding changes/additions to already existing interfaces. What are the opinions of others here regarding this? Do we need to make some procedural changes and if so what kind? Or are things working good enough as they are? Jonas [0] http://lists.freedesktop.org/archives/wayland-devel/2015-April/021465.html _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
