... snip ... On Thu, Oct 8, 2015 at 12:56 PM, Daniel Stone <dan...@fooishbar.org> wrote: > Hi, > > That's a fair (and accurate) criticism, but again I don't think that > needs one big cheese. There are quite a few people here who I think > are fairly empowered to shut down discussions that rathole into > totally unrelated topics - I (try to) do it on a semi-regular basis, > and I don't see why any current active developer shouldn't feel > empowered to, either. I think we all need to do a much better job at > enforcing S:N ratios. For my part, I'll try to be more proactive with > our primary source of noise - who is capable of producing excellent > signal at times, but ... > >> One of the reasons I don't hack on xdg-shell is because new features I >> want to propose would be stuck in the bikeshed forever. > > Fair enough, but again I think we can do that without a designated big > cheese. I think it's pretty rare that core developers have endless > bikeshed disagreements; they seem to mostly be random drive-by > disagreements on the list. > >> This is what I believe we lost when Kristian stepped down, not just a >> gatekeeper. Someone who can help model solutions and solve problems. >> >> I would love to be that person for xdg-shell, of course, but you guys >> likely wouldn't trust me. > > I assume you mean me here, and that's not actually as true as you > think it is ... > > 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. > 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. 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. 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. > - 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? > - 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. > 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. -- Jasper _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
