State of Wayland protocol development

[Jasper St. Pierre]

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.

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.

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.

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