State of Wayland protocol development

[Daniel Stone]

Hi,

On 8 October 2015 at 17:35, Jasper St. Pierre <jstpierre at mecheye.net> wrote:
> My issue with this whole "we don't have a maintainer" thing is that we
> don't have someone to make a decision. I have lots of patches and
> ideas that I'd love to contribute (and have attempted in the past),
> but usually the result is that there's some bikeshedding and
> discussion on the list, and then no action plan for how to go forward
> from here. There's just the remnants of an argument.
>
> I would love for someone to be the key decision maker, be able to say
> "yes" or "no", and then have that be the decision. See something like
> the recent present / serial argument. Trust effectively delegates to
> that person.

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.

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
  - is still using an unstable version mechanism which thwarts every
attempt at client discovery
  - 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)

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.

Cheers,
Dan

> On Tue, Sep 29, 2015 at 9:34 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> Hi,
>> Leaving the more mechanical issue of how we deal with extension
>> development for the moment ...
>>
>> On 29 September 2015 at 14:53, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>> On Tue, 29 Sep 2015 14:02:52 +0200
>>> Carlos Garnacho <carlosg at gnome.org> wrote:
>>>> On Mon, Sep 21, 2015 at 2:28 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>>> > Technically, people with push rights make the final decision to push or
>>>> > not. I'd love it if it was easy to decide what to push and what not,
>>>> > but it isn't and I don't think it can be as everyone evaluates everyone
>>>> > else differently and based on the topic at hand.
>>>>
>>>> It sounds like a lack of definition of "consensus" :)
>>>
>>> Yeah. Every person has their weight, which differs a bit based on who
>>> you ask, I presume. I tend to be too careful in what I push and not
>>> trusting others enough, and that makes me very slow in reviewing and
>>> pushing things (talking about all of Wayland and Weston).
>>>
>>>> > My view is Weston-centric as I don't work on any other compositor. My
>>>> > biased preference for not-desktop-specific extensions that aim for
>>>> > Wayland core is to be developed in Weston, be that in topic-branches or
>>>> > otherwise. Topic-branches would get the stuff off the mailing list
>>>> > early, and merging a topic-branch to master would correspond to what we
>>>> > currently have with landing patches to master.
>>>> >
>>>> > I have a feeling, that we're trying to engineer a solution to a
>>>> > political and time management problem. I'm not sure that having
>>>>
>>>> And that's I think the root of the problem. Having different agendas
>>>> is understandable, however it's IMO a maintainer duty/chore to
>>>> coordinate the intents of other contributors, or at least grasp their
>>>> priorities. If things fall out of the span of time/attention/expertise
>>>> available, we get the current situation where quite a few threads in
>>>> the ML lack direction or plainly get poor S/N ratio.
>>>
>>> I can't argue with that.
>>>
>>> For a historical reference over a year ago:
>>> http://lists.freedesktop.org/archives/wayland-devel/2014-August/016809.html
>>>
>>> I don't think we've really had a maintainer since krh. I tried to take
>>> over reviewing and releasing things and got exhausted, then Bryce took
>>> over managing releases and I've tried to concentrate on areas I know
>>> but I have limited energy.
>>
>> For my part, I don't think we really need an active maintainer in the
>> sense that we had krh at the beginning, or that we had pq
>> subsequently. If you look at the role Bryce has played in the last few
>> months, it's very different, and I think for the better - though in
>> need of some tweaks.
>>
>> It's probably most helpful to look at the context in which we had our
>> maintainers, and the way Wayland development has ebbed and flowed. krh
>> was building Wayland quite literally from scratch, at which point you
>> really need a single person to ensure that your vision is in any way
>> coherent; especially when a lot of the work really involved working on
>> Mesa/EGL, the kernel, and the toolkits simultaneously. By the time
>> Kristian stepped out, Wayland had got to the point where it's entirely
>> recognisable from today. I'd characterise the period of pq's active
>> single-person maintenance as building Weston: taking it from a
>> plaything to something shippable, not just radically remoulding it
>> internally, but also keeping a very close eye on its scope.
>>
>> Now with Wayland and Weston being bedded down, we have Bryce
>> essentially acting more as a release manager than maintainer - where
>> it's less about imposing or creating a vision, and more about ensuring
>> that independent streams of development flow smoothly. I think this is
>> pretty appropriate for the position we're in now.
>>
>> Looking at the bigger issues, we have:
>>   - the perennial xdg-shell issue
>>   - the perennial testing issue
>>   - libweston
>>   - bulking up compositor-drm, e.g. with atomic modesetting
>>   - working better with EGL/EGLImage, e.g. for dmabuf import
>>   - Vulkan
>>   - stabilising and bedding down several extensions (pointer-lock,
>> scaler, presentation-time, IVI, etc)
>>   - outreach to help external users, e.g. toolkits and other environments
>>   - a long tail of misc and other
>>
>> I don't think these necessitate a single gatekeeping maintainer in the
>> way that Kristian and Pekka were, or in the way that Keith was for
>> xserver until a week or two ago. I think each of these need a
>> designated maintainer/go-to person: someone we trust knows the issues,
>> someone we trust to be considerate of their impact on Wayland/Weston
>> themselves and other wider projects, and someone we know works well
>> with all involved with it. This seems to be true of most all
>> components; I've certainly had my concerns with xdg-shell's
>> development (primarily how it seemed to have stalled a while ago, and
>> its merge into Weston probably being premature), but it seems like we
>> have more effective maintenance for the future.
>>
>> Being all independent streams, they require different skillsets and
>> backgrounds: I'll happily talk to you about KMS, about EGL
>> integration, about media and presentation/timing, but I'm singularly
>> unqualified to give my opinion on xdg-shell toolkit integration
>> issues, on the whole.
>>
>> Taking a step back, I think we should be looking at:
>>   - how do we set the parameters for what we think is acceptable or
>> good to have? really just classic release planning - set our dates and
>> our boundaries, and any goals/expectations we have for those releases;
>> something we've not always been great at, but with some more planning,
>> discussion and visibility on list, I think we can do a much better job
>> of this
>>   - how do we best help people contribute within those boundaries? if
>> someone is doing work we've all agreed on in principle, and it's got
>> sufficient review, to me this is really about empowering them to push
>> through directly; dropping the expectation that people other than
>> Bryce/Pekka/myself pushing is some kind of weird event, or only done
>> for trivialities
>>   - how do we best help newcomers contribute? we're not always
>> fantastic at getting review out, though Bryce/Derek/et al in
>> particular have been fantastic at trying to sweep up Patchwork, and
>> this does seem to improve
>>   - how do we avoid compromising on quality? I've been hoping to
>> really beef up our CI to help with this
>>   - how do we deal with anything outside the bounds we have now? what
>> happens when something challenges the comfortable scope above?
>>
>> This last question is definitely the more difficult one, and certainly
>> we've been guilty of arguing around each other whilst these larger
>> questions flail a little bit. But I think if we can resolve that, we
>> move away from a requirement to have someone who will in all
>> statistical probability try to burn out, and make better use of
>> everyone's time.
>>
>> Cheers,
>> Daniel
>
>
>
> --
>   Jasper