Wayland and Weston 1.5.0 is released

Wed May 21 00:12:08 PDT 2014

2014-05-20 23:12 GMT+03:00 Kristian Høgsberg <hoegsberg at gmail.com>:
> Hi,
>
> I tagged 1.5.0 of Wayland and Weston and uploaded tar balls last
> night.  Tarballs available from
> http://wayland.freedesktop.org/releases.html as usual.  Magic SHA1
> number for the tags and tar balls:
>
>   bace08b4a531ea4b80b4cf4e953320bc48ed7efe  wayland-1.5.0.tar.xz
>   3ac62cd6b6012f40e37b1bd7fc1e8178585905ca  wayland 1.5.0 tag
>
>   42939c536bcdfbd92edb5e51af76ce7f0a4c6ed7  weston-1.5.0.tar.xz
>   880193622024d7dc2b36421251d97b08da324570  weston 1.5.0 tag
>
> In retrospect, this release was pretty quiet.  We ended up not merging
> a whole lot of features, but we did fix a lot of bugs and at one point
> the bug count [1] hit 14, the lowest in a long time.  I think that's a
> pretty good feautre in itself.
>
> Wayland
>
>  • Use an internal event queue for wl_display events.  This allows the
>    client library to dispatch delete_id and error events immediately,
>    even if the default queue is not dispatched.
>
>  • Wayland now uses non-recursive Makefiles.
>
> Weston:
>
>  • More work on xdg-shell, still not complete.  We did add the long
>    missing minimize feature thought.  We expect to finalize the
>    xdg-shell interface in time for 1.6, which will come out in time
>    for GNOME Shell 3.14 to use.
>
>  • The weston input stack was split out as a new library, libinput.
>    Weston can be configured to link to libinput for input but defaults
>    to the built in input code for now.  As the libinput API
>    stabilizes, we'll remove the in-weston input code and make libinput
>    a hard requirement.
>
>  • Weston now uses the new Xwayland server.  The Xwayland code was
>    refactored to be its own X server in the Xorg tree, similar to how
>    Xwin and Xquartz and Xnest work.  A lot of the complexity and hacks
>    in the old Xorg based Xwayland was about fighting Xorg trying to be
>    a native display server, discovering input devices and driving the
>    outputs.  The goal was to be able to reuse the 2D acceleration code
>    from the various Xorg DDX drivers.  With glamor becoming a credible
>    acceleration architecture, we no longer need to jump through those
>    hoops and the new code base is much simpler and cleaner as a
>    result.  Xwayland is upstream now and will be released with the
>    1.16 Xorg release.
>
>  • Animate window closing.  A minor feature, but it validates the
>    mechanism for keeping surfaces around after the client that created
>    them goes away.
>
>  • Fullscreen shell.  The fullscreen shell provides a mechanism for a
>    single client to provide a fullscreen surface, for kiosk-mode or
>    appliance type use cases.
>
>  • Weston now supports different color dephts on different outputs.
>
>  • Weston now uses non-recursive Makefiles.
>
> As I mentioned in the RC2 notes, we have a few things lined up for a
> 1.5.1 release and we'll try to get that out in a few weeks.  As for
> 1.6, we'll try to do four months from now, so something like this:
>
>  • Mid August: alpha release, all big features landed, only minor,
>    contained features after this.
>
>  • Early September: RC1, only bug fixes after this.
>
>  • One week later: RC2, only critical fixes.
>
>  • Mid September: Release 1.6 should be RC2 ideally.
>
> Going forward, for master, I'd like to change the work flow a bit.
> The biggest problem with how we work today is me being a bottleneck at
> best or flat out dropping patches.  So I'd like to open up commit
> access to some of the key contributors.  Either people that have their
> corner of weston that they maintain (for example Pekka and the
> Raspberry Pi backend or Hardening and the RDP backend) or contributors
> who have been part of the project for a while and understands the code
> base well - or both.

Kudos for this. I'd also like some patch tracking tool, but this is
already a big thing imho. Thanks.

>
> Being able to review *and* commit a patch will hopefully increase the
> incentive to review and I won't need to be around all the time for
> things to move forwards.  I think everybody has enough common sense to
> decide when something is a quick fix that can be committed right away
> and when something needs wider discussion and concensus.  For anything
> that touches core weston and in particular, anything that adds
> protocol, we still want to see patches, reviews and discussion the
> list before committing.
>
> Thanks to everybody who contributed to 1.5, let's start talking about
> what we want to do for 1.6.
>
> Kristian
>
> [1] https://bugs.freedesktop.org/buglist.cgi?list_id=279166&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&product=Wayland
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel