State of Wayland protocol development

[Daniel Stone]

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