State of Wayland protocol development

Tue Sep 29 06:53:25 PDT 2015

On Tue, 29 Sep 2015 14:02:52 +0200
Carlos Garnacho <carlosg at gnome.org> wrote:

> Hi Pekka,
> 
> On Mon, Sep 21, 2015 at 2:28 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Fri, 18 Sep 2015 22:44:16 +0800
> > Jonas Ådahl <jadahl at gmail.com> wrote:
> >
> >> On Fri, Sep 18, 2015 at 04:35:52PM +0300, Pekka Paalanen wrote:
> >> > On Fri, 18 Sep 2015 15:00:19 +0800
> >> > Jonas Ådahl <jadahl at gmail.com> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I'd like to start a discussion on the state of how development of Wayland
> >> > > interfaces are done and how they should be done, though less about the
> >> > > technical aspect of it.

> >> > Should we be using a different Weston branch for including all the
> >> > experimental stuff while leaving master for "stable development"? Nah,
> >> > I think that might become a mess.[*]
> >>
> >> I don't think we should. Branches will bit-rot and it will be a pain to
> >> have to rebase them over and over again. They will also be harder to
> >> discover and test. The main goal really is to make it more obvious where
> >> to find in-progress protocols, and I don't think hiding them in branches
> >> helps that much.
> >
> > The idea was to periodically merge master into the topic-branch, not
> > rebase. So a topic-branch would be easily at least as recent as master.
> >
> > I first thought one branch for everything experimental and rejected
> > that idea, but topic-branches is an idea I haven't rejected yet.
> >
> > When someone wants to propose a topic branch to be merged, it is easy
> > to generate the diff to master. Reviewing that would be hopefully
> > easier than rebase/squash/resend cycle, and it wouldn't invalidate old
> > testing.
> 
> IMO Topic branches still have a problem of discoverability (although
> to a lesser extent than patches in the ML). Branches in the main
> wayland/weston repos would seem the most "official" way, but can be
> done only by the selected few. Others (amongst them me) have fdo
> account, so the feature branches could at least be in a ~username repo
> at git.freedesktop.org. For other less fortunate ones, there might not
> be other option than github or others.

Hi,

I was thinking the upstream repositories specifically.

> Let me suggest something similar to gstreamer bad plugins, having a
> "wayland-unstable" repo that gathers all latest versions of non-core
> protocols. Unfortunately these are nothing without an implementation,
> so I'd suggest making this repo compile into a noinst library for
> basic tests, and require compositors to copy xmls from there. The push
> requirements could be more relaxed (eg. any patch s-b or r-b the
> maintainers or the authors of the specific protocol gets in,
> implementations somewhere other than weston suffice to get this
> in,...), this is minor maintenance burden that might be even
> delegated. Ideally but not mandatorily, updates to a protocol in that
> repo should come together with weston patches that would get the
> full-blown protocol+code review, but the unstable repo would always
> contain the last instance of the protocol. And of course these could
> become "core", at which point they should probably be removed from the
> repo and bumped (versioning, removing prefixed '_', whatnot).

Yup, that sounds quite much like Jason's separate repo proposal, with
more details.

It seems the idea of copying XML files to downstream projects is fairly
popular, it does avoid a lot of dependency-versioning problems.

> IMHO the advantages are:
> 
> - All unstable protocol pieces are in a central place
> - The pre-stable history is preserved somewhere, instead of scattered
> across the compositors/toolkits that dare implement that.
> - it allows developers of other compositors to play early with the
> protocol and chime in ASAP, maybe they could even lead to stabilized
> protocol changes before the weston patches get proper review, and
> higher quality patches left for you to review in the end.

All true.

However, I cannot be the judge here. Even though I've worked on a
number of protocol extensions, I haven't felt missing out too much.

Well, except for feedback. Yes, I've craved for feedback at times, but
when no-one says anything new, I'll just continue upstream and towards
stabilizing things. For better or worse. After I have let the protocol
lay dormant in Weston for a year thinking it has stabilized, making it
officially stable was easy - and then later I start getting feedback
when the ship has already sailed.

If there is something we could do for that, that would be excellent.

> >> The other part I brought up was adding to stable protocols. Currently
> >> being discussed are additions to wl_data_device_manager (DND actions),
> >> wl_seat (release request), wl_pointer (axis sources), wl_touch
> >> (touch "focus" changes). Who are in charge of allowing such changes?
> >> Some are quite huge (DND actions) and without a consensus, while the
> >> other are relatively small, and thus with a consensus easier to reach,
> >> but who's responsibility is it to make the call?
> >
> > Whoever is a known expert on that area.
> >
> > Who decides who is an expert? Uhh...
> 
> It wouldn't be good if every maintainer thinks like that :), even
> worse if that results in no action taken... I understand the
> difficulties of knowing/picking such go-to person, or becoming an
> expert yourself on whatever topic there is at hand, but I would like
> to point out the vicious circle where slow review lead to "becoming
> trusted" taking ages, so the amount of people that have a say remain
> static and overburdened.

That's definitely a problem we have. Do you have any suggestions how to
overcome that?

> Anyhow, being probably desktop-biased here, I think the rightful first
> questions to ask around additions to stable protocols are:
> 
> - Can this be done through an external protocol?

+ Can this be done through a new protocol extension rather than
  augmenting a stable interface?

> - Does the lack of this feature hinder adoption or feature parity? to
> which extent?
> 
> The reply to these should give an idea of how apt is a change to the
> stable protocol, and the celerity required.
> 
> >
> > 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.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150929/d0fd6820/attachment.sig>