State of Wayland protocol development

[Daniel Stone]

Hi,

On 8 October 2015 at 21:43, Jasper St. Pierre <jstpierre at mecheye.net> wrote:
> On Thu, Oct 8, 2015 at 12:56 PM, Daniel Stone <daniel at fooishbar.org> wrote:
>> The issues I had with earlier xdg-shell development mostly centred
>> around your frustration with bikeshedding leading to pulling out of
>> all discussion and just periodically pushing changes to a GitHub
>> branch literally no-one knew about, with no plan to push it upstream.
>> I think it's fairly obvious that that isn't a sustainable approach for
>> a maintainer. There were a couple of others, but after our discussion
>> the other day I'm much more relaxed about that, and if you (or someone
>> else nominated) wanted to step up and actively push and proactively
>> steer xdg-shell maintenance in a way which was transparent to the
>> community, I'd be thrilled.
>
> This is correct. A large amount of xdg-shell came out of one-on-one's
> with Kristian. Talking about the race conditions I was hitting, about
> experiences with wl_shell, things that made me uncomfortable, and
> possible solutions.
>
> I doubt the same protocol, something we are both very proud of, would
> have arisen through design by committee^W ML discussion.

I agree. But by the same token, we don't have Kristian anymore.
Neither Pekka nor myself have sufficient depth in toolkit-level
integration issues to be able to have those productive discussions. So
fine, that rules us out: but by the same token, I'd say that we're
probably the best placed to deal with media integration (also pretty
crucial), timing issues, DRM/KMS usage, EGL integration, etc etc. I
don't believe we have anyone with the same breadth and depth of
understanding that Kristian has.

But again, this is partly due to context: the depth we're exploring
these issues in now, is much greater than it ever was. So yes,
generalism is good - and I've been trying to push myself to find out
more about the areas I don't know too well, and very happy with how
some of our other core developers have been doing the same - but you
do need specialists in the particular areas.

And just before we get too rose-tinted, Kristian wasn't infalliable
either. I remember explaining to him why his proposed input model -
something we'd been at loggerheads about for months - wouldn't fly,
starting with caps lock not working. :)

>> Part of my frustration with that was entangled with xdg-shell itself, which:
>>   - is lacking a clear path (at least, a clear documented path) to 1.0
>
> My path, from a year ago, was in the form of "xdg-shell: Make stable".
> I thought it was ready at the time.
>
> http://lists.freedesktop.org/archives/wayland-devel/2014-July/016056.html
>
> Several people had excellent editorial concerns, which we've since
> fixed. At some point, the consensus was that is that it's too early to
> make stable, and requires feedback from other communities like KDE,
> XFCE, and EFL.
>
> Recently (meaning earlier today) an EFL developer has gotten back to
> me with some feedback. What we've decided might entail a more complex
> and breaking set of changes to xdg-shell to meet new requirements.
> Talk about adding new roles like tooltips and dialogs, and adding the
> configure event to xdg_popup as well.

Great! That sounds really good.

> We'll see what these entail in the long run. These are sometimes
> fairly big hard-to-justify shifts, and I'm not sure if a mailing list
> is the best place to ask about them. I'm tempted it's a big too
> heavy-weight for trying out changes like this.

One of my frustrations with our current review, is that discussion of
the overall approach and bikeshedding of individual details, all get
mashed into one. One of the things I like about Phabricator, after
having rolled it out through Collabora and also to fd.o, is that you
can separate the two, with overall discussion of the approach being on
the task (bug), and individual review happening on each commit. There
are a lot of other things to like about it, including linking (and
diffing between) different versions of reviews, being able to see the
overall status of a patchset from the task, CI triggers, etc.

That may be another discussion, but if you think it'd be easier to
use/track than email, then I'm happy to step through usage of it and
the tools we've got to make patchset submission easier.

> There was talk about a "present" request, which has been floating
> around the ML. I'd be happy to see it incorporated, but I don't have
> any power over the patch landing.

Me neither. But it's been reviewed, people seem generally happy with
it, and without being too presumptuous, it seems like the blocking
question of invalid serial numbers, has landed on separate requests.
So all that's really left is to land it with the slight rename and two
separate requests. Again though, xdg-shell isn't my area of expertise,
so I'd be much happier with someone like Jonas committing it.

>>   - is still using an unstable version mechanism which thwarts every
>> attempt at client discovery
>
> Sure, I think a lot of us have been unhappy with the unstable version
> mechanism, me included. We have been discussing alternate ways to
> develop distribute incomplete and WIP protocols in this very thread.
> That unfortunately doesn't *do* anything. Somebody wants to step up,
> do the work, make the repos, and shepherd things going forward. I
> would bite the bullet and do it, except I don't have permissions to
> create new repos or push to the Weston repo.
>
> I would be super happy to fix this, but I don't have the privilege to.
> Do you want to volunteer?

Jonas's proposal looks good to me; I think the thing to do is to let
it settle over the weekend, and then I can create the repository.

>>   - was being developed out-of-tree with little review, having new
>> versions parachuted in as a fait accompli since it was already pushed
>> to Mutter and GTK+ (but again, to be fair, this only happened once and
>> hasn't since)
>
> This is unfair. With every protocol change, the Weston implementations
> were developed before the mutter and GTK+ ones. But Weston is a toy --
> the clients are not real applications, and the compositor isn't a
> complete window manager. mutter was hitting race conditions and
> problems that Weston didn't hit, because it didn't have the same
> expanded feature set.
>
> xdg-shell was developed in close coordination with mutter and GTK+,
> yes, because those were the codebases I knew the most. But Weston
> support wasn't an afterthought, and we never simply shoved it in
> without thinking.

This did actually happen with xdg-shell v5, where it got committed to
GTK+/Mutter first, making its merge into Weston a total fait accompli,
as it was already deployed.

I'm not rehashing these last points to crucify anyone, to gripe at the
state of xdg-shell, or to suggest that anyone in particular is unfit
to maintain it. This was solely to provide some context as to why -
just as it was for you - xdg-shell's early development was also a
pretty frustrating time for me, and thus why some of the discussions
we had around it weren't as productive as they should've been.

>> Any kind of plan to solve these issues - and I do believe there is
>> one, just not necessarily documented in a clear way for the benefit of
>> the wider community - would be really welcome.
>
> The thing about an action plan is that somebody needs to execute it. I
> don't think we have anybody dedicated enough to execute right now,
> which is a major problem.

Sure, but again this is all about xdg-shell, not about Wayland in general.

Both myself and Pekka have disclaimed ourselves from any position of
responsibility with xdg-shell; I'd love to see someone step up, and so
far it looks like we have at least one and a half volunteers, which is
good.

Cheers,
Daniel