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

[Uli Schlachter]

Hi,

On 15.11.2013 08:18, Arnaud Fontaine wrote:
> 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...

I can live with that. "XKB was disabled by default for a reason, deal with it."

>>    - ("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.

What kind of API stability are we trying to guarantee with xcb? Can we just
break the API in minor releases ("on purpose", in contrast to "accidentally")?

I find it surprising that we agree on breaking the API so easily.

>>   - 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?

Sure, fine with me, but I don't really know all the glory details about XKB.
Didn't we also have some patches messing with XI?

My approach was "ABI was broken accidentally, fix this". I don't mind going with
"ABI was broken accidentally, but we need this breakage anyway".

Should we put a note into NEWS (where no one will read it) saying that
libxcb-xkb.so and the headers from 1.9.2 and 1.9.3 should be avoided?

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

Ok, so I guess the "another release from a branch"-idea is dead then and we try
to get master into a sane state. I'll try to collect a new todo list for this
and send it off tomorrow. But this means that people can review the needed
patches and commit them already... :-)

Let's see how long proto 1.9.1 and libxcb 1.9.3 will stay in Arch and Gentoo...

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

(Could someone with more clue about proto review this? It seems to be obviously
correct, but I don't really ever touched proto)

> libxcb-master:
>>   - Merge all the NEWS entries from the releases
>>   - bump XKB soname
>>   - bump XCB soname

What? Why? You mean the soname for libxcb.so, right? AFAIK there was no ABI
breakage here (if you don't count "adding new symbols" as breaking ABI).

>>   - 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?

Possible. I never used this magic and I the comments from Mouse which I
forwarded to this list don't really make me happy.

>> 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!

Now we just need someone with enough access rights to mark patches as merged in
there...

Cheers,
Uli
-- 
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?