[Xcb] New libxcb and xcb-proto releases (code name: "Oh, shit")

Arnaud Fontaine arnau at debian.org
Thu Nov 14 23:18:32 PST 2013


Hi,

Uli Schlachter <psychon at znc.in> writes:

> as you may have noticed, things went a little downhill after the latest
> releases. Let's try to fix this without breaking more stuff. Since no one showed
> up for a week (and I am trying to avoid doing the things I am supposed to do),
> here is what I thought about and wrote down:
>
> First some more emergency releases (based on branches ontop of the latest releases):
> - Create branches based on the latest releases for both libxcb and xcb-proto
> - proto:
>   - Remove that evil tab (python 3 compatibility)
>   - revert the introduction of GE events to the XML
>    - revert the XKB ABI issue (we end up with a broken definition for GetNames
> and GetMap, but at least it will be as broken as in 1.9)

Well, considering that it was broken before and that XKB is not even
enabled by default, I don't think it should be reverted, instead we
should bump only the soname IMO...

>    - ("remove reference to nonexistant enum" since Peter asked for it)
> - libxcb:
>   - Revert the removal of xcb_ge_event_t

It was an ugly hack to access pad0 anyhow and this is a necessary fix
IMO, so I agree with Julien that it should not be reverted.

>   - depend on the next proto release

> After the release:
> - xcb-proto master:
>   - Merge all the NEWS entries from the releases
>   - revert GE introduction (cherry-pick from release?)
> - libxcb master:
>   - Merge all the NEWS entries from the releases
>   - revert GE removal (cherry-pick from release?)
>   - bump XKB soname
>   - revert 9ae84ad187e2ba440c40f44b8eb21c82c2fdbf12 ("fix deadlock with
> xcb_take_socket/return_socket v3")

Considering this list of steps is fairly small and that we have
unfortunately already broken the ABI, I think it should be better to go
forward (especially considering that the patches breaking the ABI are
correct at the end) and bump sonames instead of reverting and breaking
the ABI again later on.

Moreover, master branch contains many XKB patches from Daniel and Ran
which would allow XKB to be enable by default (Cc'ing Ran and Daniel to
confirm that) but break the ABI too. Even if we don't necessarily have
to enable it for this release, I think it's better to do it now in order
to avoid breaking the ABI later. What do you think?

If we follow this idea, it would mean there are the following things to
do before the release from master branch:

xcb-proto master:
>   - Merge all the NEWS entries from the releases> 
>   - ("remove reference to nonexistant enum" since Peter asked for it)

libxcb-master:
>   - Merge all the NEWS entries from the releases
>   - bump XKB soname
>   - bump XCB soname
>   - revert 9ae84ad187e2ba440c40f44b8eb21c82c2fdbf12 ("fix deadlock with
> xcb_take_socket/return_socket v3")

Also, probably "[PATCH libxcb] Fix alignment issues in FD passing code"
should be merged as well?

> P.P.P.S.: FDO bug #44690 "Add xcb to patchwork" was resolved. Sadly, I cannot
> mark patches as "merged" yet, but at least it now tracks patches sent to the ML.
> See http://patchwork.freedesktop.org/project/xcb/list/

Really nice, it was not convenient at all to track patch
before... Thanks!

Cheers,
-- 
Arnaud Fontaine


More information about the Xcb mailing list