Hi, I will update the website later tonight or tomorrow, I've been travelling so it's a bit hectic :-)
Yes we discussed this a while ago, and thanks to the DRAFT APIs mechanism we can now stay on the same repository. Any unstable API will simply not be available unless enabled at build time. This way we get all the bug fixes without having to backport and when a new API is ready we mark it stable and enable it. On Sat, 2016-11-05 at 09:42 +0100, Michal Vyskocil wrote: > Hi, > > great work! > > I noticed the zeromq.org download page > http://zeromq.org/intro:get-the-software hasn't been updated yet. > > I also found out that the 4.2.0 release was tagged in libzmq > repository instead of zeromq4-2 fork. Does it means that zeromq > project is moving away from fork model for releases? Or it's just for > a zero release? > > Bye > Michal > > On Sat, Nov 5, 2016 at 8:44 AM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > > Final status update: > > > > CZMQ 4.0.0 is out, announcement has been sent: > > > > https://github.com/zeromq/czmq/releases/tag/v4.0.0 > > > > What a ride :-) > > > > libzmq 4.2.0 has been already uploaded to Debian (Thanks László for the > > very quick upload!), now I hope I can get CZMQ 4.0.0 up too by tomorrow. > > > > On Fri, 2016-11-04 at 13:35 +0000, Luca Boccassi wrote: > >> Status update: > >> > >> CZMQ release notes PR is open: > >> > >> https://github.com/zeromq/czmq/pull/1542 > >> > >> I will be travelling now until the evening (might have some time at > >> airport), so if you have anything to add please merge and send a new > >> PR :-) > >> I would like to release v4.0.0 tonight, so that I can (barely!) make it > >> for Debian 9 transition freeze. Phew! > >> > >> On Fri, 2016-11-04 at 10:46 +0000, Luca Boccassi wrote: > >> > Status update: > >> > > >> > libzmq 4.2.0 is out! Email sent to the announce list. > >> > > >> > https://github.com/zeromq/libzmq/releases/tag/v4.2.0 > >> > > >> > CZMQ is next! > >> > > >> > On Fri, 2016-11-04 at 09:52 +0000, Luca Boccassi wrote: > >> > > Status update: > >> > > > >> > > Added missing CTX option to CZMQ, retired more deprecated methods that > >> > > are in STABLE classes. > >> > > > >> > > Fixed a few typos in the rel notes (thanks Himikof and Paddor!), still > >> > > waiting for someone to merge: > >> > > > >> > > https://github.com/zeromq/libzmq/pull/2189 > >> > > > >> > > > >> > > On 3 November 2016 at 09:34, Luca Boccassi <luca.bocca...@gmail.com> > >> > > wrote: > >> > > > Status update: > >> > > > > >> > > > I've added all the missing options to CZMQ (check please!), and I > >> > > > prepared > >> > > > the release notes for libzmq 4.2, waiting for a merge: > >> > > > > >> > > > https://github.com/zeromq/libzmq/pull/2189 > >> > > > > >> > > > Anything else we should mention? > >> > > > > >> > > > > >> > > > On Nov 1, 2016 21:33, "Luca Boccassi" <luca.bocca...@gmail.com> > >> > > > wrote: > >> > > >> > >> > > >> Status update: > >> > > >> > >> > > >> libzmq 4.1.6, libzmq 4.2.0-rc1 and czmq 4.0.0-rc1 are out on Github: > >> > > >> > >> > > >> https://github.com/zeromq/zeromq4-1/releases/tag/v4.1.6 > >> > > >> https://github.com/zeromq/libzmq/releases/tag/v4.2.0-rc1 > >> > > >> https://github.com/zeromq/czmq/releases/tag/v4.0.0-rc1 > >> > > >> > >> > > >> I'll send an email to the announce list shortly. As I wrote earlier > >> > > >> I'll work to have proper release notes for the stable releases. > >> > > >> > >> > > >> Unless there are any objections, I'm aiming to push libzmq 4.2.0 > >> > > >> stable tomorrow by the end of the day, and czmq the day after. > >> > > >> > >> > > >> It's an aggressive schedule, but I would _really_ like to get CZMQ > >> > > >> 4.0.0 in Debian and the transition freeze date is Saturday (ABI/API > >> > > >> is > >> > > >> borken so there needs to be a transition), and for that I need > >> > > >> libzmq > >> > > >> up before it. > >> > > >> > >> > > >> Any objections? > >> > > >> > >> > > >> I've also noticed that not all the libzmq socket options are > >> > > >> available > >> > > >> in CZMQ, so this gives me some time to fix that. > >> > > >> > >> > > >> > >> > > >> On 1 November 2016 at 14:48, Doron Somech <somdo...@gmail.com> > >> > > >> wrote: > >> > > >> > Great news! > >> > > >> > > >> > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi > >> > > >> > <luca.bocca...@gmail.com> > >> > > >> > wrote: > >> > > >> >> > >> > > >> >> Status update: > >> > > >> >> > >> > > >> >> - v2 APIs are gone from CZMQ: > >> > > >> >> https://github.com/zeromq/czmq/pull/1531 > >> > > >> >> https://github.com/zeromq/czmq/pull/1532 > >> > > >> >> - PR is out to bump the libtool version and changelog for libzmq: > >> > > >> >> https://github.com/zeromq/libzmq/pull/2184 > >> > > >> >> - PR is out to backport the zmq_msg_t fix to 4.1: > >> > > >> >> https://github.com/zeromq/zeromq4-1/pull/155 > >> > > >> >> > >> > > >> >> Once it's all merged I will tag 4.2.0~rc1 first, then release > >> > > >> >> 4.1.6 > >> > > >> >> from > >> > > >> >> zeromq4-1 since quite a few fixes have accumulated. Then I'll > >> > > >> >> send PRs > >> > > >> >> to prepare for CZMQ 4.0.0~rc1. > >> > > >> >> > >> > > >> >> After the RCs are out, I'll work on the changelogs/NEWS files > >> > > >> >> (help is > >> > > >> >> appreciated!) as they have fallen dramatically behind. > >> > > >> >> > >> > > >> >> I'll also prepare more formal release notes for the stable rels, > >> > > >> >> the > >> > > >> >> RCs > >> > > >> >> will have just a quick note since they are RCs. > >> > > >> >> > >> > > >> >> On Mon, 2016-10-31 at 23:47 +0000, Luca Boccassi wrote: > >> > > >> >> > Cool! > >> > > >> >> > > >> > > >> >> > I can take care of it if you like. Tentative plan: > >> > > >> >> > > >> > > >> >> > Tomorrow push an RC1 for libzmq, then the pr to CZMQ to retire > >> > > >> >> > v2 > >> > > >> >> > APIs, > >> > > >> >> > then the RC1 for CZMQ. > >> > > >> >> > > >> > > >> >> > If it's all good then a couple days later the finals. I would > >> > > >> >> > really > >> > > >> >> > like > >> > > >> >> > to make it for the debian 9 transition freeze which is > >> > > >> >> > Saturday. > >> > > >> >> > > >> > > >> >> > On Oct 31, 2016 22:23, "Doron Somech" <somdo...@gmail.com> > >> > > >> >> > wrote: > >> > > >> >> > > >> > > >> >> > > Sorry, yes, lets do it :) > >> > > >> >> > > > >> > > >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" > >> > > >> >> > > <luca.bocca...@gmail.com> > >> > > >> >> > > wrote: > >> > > >> >> > > > >> > > >> >> > >> Ping :-) > >> > > >> >> > >> > >> > > >> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" > >> > > >> >> > >> <luca.bocca...@gmail.com> > >> > > >> >> > >> wrote: > >> > > >> >> > >> > >> > > >> >> > >>> I have sent a solution for the alignment problem that > >> > > >> >> > >>> solves the > >> > > >> >> > >>> sigbus > >> > > >> >> > >>> problem without breaking ABI compat (plus follow-up for > >> > > >> >> > >>> VC++ - > >> > > >> >> > >>> sorry > >> > > >> >> > >>> Windows guys https://github.com/zeromq/libzmq/pull/2179 ). > >> > > >> >> > >>> > >> > > >> >> > >>> I tested the alignment and sigbus problem on x86_64 by > >> > > >> >> > >>> enabling > >> > > >> >> > >>> alignment check with: > >> > > >> >> > >>> > >> > > >> >> > >>> __asm__("pushf\norl $0x40000,(%rsp)\npopf"); > >> > > >> >> > >>> > >> > > >> >> > >>> All was fine. > >> > > >> >> > >>> > >> > > >> >> > >>> I ran tests built from the zeromq4-1 repository against a > >> > > >> >> > >>> shared > >> > > >> >> > >>> lib > >> > > >> >> > >>> from the head of libzmq repo, and they all run fine minus > >> > > >> >> > >>> the > >> > > >> >> > >>> ZMQ_REQ_CORRELATE one but that option was borken anyway. > >> > > >> >> > >>> > >> > > >> >> > >>> This allows us to do a release now, and then when we are > >> > > >> >> > >>> ready we > >> > > >> >> > >>> can do > >> > > >> >> > >>> the ABI breakage, without blocking 4.2. Which is nice > >> > > >> >> > >>> since it > >> > > >> >> > >>> means > >> > > >> >> > >>> it > >> > > >> >> > >>> might make it for Debian 9! > >> > > >> >> > >>> > >> > > >> >> > >>> So, Doron et al, shall we do the bump this weekend? > >> > > >> >> > >>> > >> > > >> >> > >>> On Thu, 2016-10-20 at 17:12 -0500, Thomas Rodgers wrote: > >> > > >> >> > >>> > I will have some time most likely the week of Nov6 (off > >> > > >> >> > >>> > for a > >> > > >> >> > >>> > week > >> > > >> >> > >>> > of > >> > > >> >> > >>> C++ > >> > > >> >> > >>> > Committee 'fun') to test different message size > >> > > >> >> > >>> > alternatives. > >> > > >> >> > >>> > I'll > >> > > >> >> > >>> follow > >> > > >> >> > >>> > up with my results here for consideration the next time > >> > > >> >> > >>> > we are > >> > > >> >> > >>> inclined to > >> > > >> >> > >>> > break the ABI compatibility :) > >> > > >> >> > >>> > > >> > > >> >> > >>> > On Sunday, October 16, 2016, Brian Knox > >> > > >> >> > >>> > <bk...@digitalocean.com> > >> > > >> >> > >>> wrote: > >> > > >> >> > >>> > > >> > > >> >> > >>> > > A new stable version would definitely help me in my > >> > > >> >> > >>> > > quest to > >> > > >> >> > >>> > > get > >> > > >> >> > >>> ZeroMQ > >> > > >> >> > >>> > > support enabled by default in rsyslog in distros. > >> > > >> >> > >>> > > > >> > > >> >> > >>> > > On Sun, Oct 16, 2016 at 2:40 PM Doron Somech > >> > > >> >> > >>> > > <somdo...@gmail.com> > >> > > >> >> > >>> wrote: > >> > > >> >> > >>> > > > >> > > >> >> > >>> > >> I say lets bump. > >> > > >> >> > >>> > >> > >> > > >> >> > >>> > >> On Oct 15, 2016 20:32, "Luca Boccassi" > >> > > >> >> > >>> > >> <luca.bocca...@gmail.com> > >> > > >> >> > >>> wrote: > >> > > >> >> > >>> > >> > >> > > >> >> > >>> > >>> As Thomas said, false sharing would be a real issue > >> > > >> >> > >>> > >>> with > >> > > >> >> > >>> > >>> 96. > >> > > >> >> > >>> > >>> > >> > > >> >> > >>> > >>> So given a release is long due, at this point I'd > >> > > >> >> > >>> > >>> say to > >> > > >> >> > >>> > >>> drop > >> > > >> >> > >>> > >>> this > >> > > >> >> > >>> for > >> > > >> >> > >>> > >>> the moment. > >> > > >> >> > >>> > >>> > >> > > >> >> > >>> > >>> What do we do for the change to union for zmq_msg_t? > >> > > >> >> > >>> > >>> Bump > >> > > >> >> > >>> > >>> ABI > >> > > >> >> > >>> version or > >> > > >> >> > >>> > >>> not? > >> > > >> >> > >>> > >>> > >> > > >> >> > >>> > >>> On Thu, 2016-10-06 at 09:53 +0300, Doron Somech > >> > > >> >> > >>> > >>> wrote: > >> > > >> >> > >>> > >>> > No new socket type, I worked at the time on binary > >> > > >> >> > >>> > >>> > message > >> > > >> >> > >>> > >>> > type, > >> > > >> >> > >>> might > >> > > >> >> > >>> > >>> > complete it sometime, but it is not urgent. > >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > If there is a lot of performance penalty we can > >> > > >> >> > >>> > >>> > give it > >> > > >> >> > >>> > >>> > up, > >> > > >> >> > >>> > >>> > I > >> > > >> >> > >>> will > >> > > >> >> > >>> > >>> > find another solution for the Radio-Dish. > >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > What about 96 bytes? same penalty? > >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > Regarding the binding, I'm not sure. > >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > On Sat, Oct 1, 2016 at 9:14 PM, Luca Boccassi < > >> > > >> >> > >>> luca.bocca...@gmail.com> > >> > > >> >> > >>> > >>> wrote: > >> > > >> >> > >>> > >>> > > On Tue, 2016-09-27 at 09:41 +0300, Doron Somech > >> > > >> >> > >>> > >>> > > wrote: > >> > > >> >> > >>> > >>> > >> Sorry for the late response, increasing the > >> > > >> >> > >>> > >>> > >> msg_t > >> > > >> >> > >>> > >>> > >> structure > >> > > >> >> > >>> will be > >> > > >> >> > >>> > >>> > >> great, however this will require changing a lot > >> > > >> >> > >>> > >>> > >> of > >> > > >> >> > >>> > >>> > >> binding. > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > I think I remember we need it for the new socket > >> > > >> >> > >>> > >>> > > types, > >> > > >> >> > >>> > >>> > > is > >> > > >> >> > >>> > >>> > > that > >> > > >> >> > >>> > >>> correct? > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > There is a large performance penalty > >> > > >> >> > >>> > >>> > > (intuitively due > >> > > >> >> > >>> > >>> > > to > >> > > >> >> > >>> > >>> > > not > >> > > >> >> > >>> fitting > >> > > >> >> > >>> > >>> > > into a single cache line anymore, but haven't ran > >> > > >> >> > >>> perf/cachegrind), > >> > > >> >> > >>> > >>> and > >> > > >> >> > >>> > >>> > > the throughput with vsm type messages goes down > >> > > >> >> > >>> > >>> > > by 4% > >> > > >> >> > >>> > >>> > > (min) > >> > > >> >> > >>> and 20% > >> > > >> >> > >>> > >>> > > (max) for TCP, and 36% (min) 38 (max) for > >> > > >> >> > >>> > >>> > > inproc, which > >> > > >> >> > >>> > >>> > > is > >> > > >> >> > >>> quite a > >> > > >> >> > >>> > >>> lot, > >> > > >> >> > >>> > >>> > > so we need to be sure it's worth it. > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > Regarding the bindings, after a quick search on > >> > > >> >> > >>> > >>> > > the > >> > > >> >> > >>> > >>> > > Github > >> > > >> >> > >>> org, I > >> > > >> >> > >>> > >>> could > >> > > >> >> > >>> > >>> > > only see: > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > https://github.com/zeromq/lzmq/blob/master/src/lua/lzmq/ > >> > > >> >> > >>> > >>> ffi/api.lua#L144 > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > https://github.com/zeromq/clrzmq4/blob/master/lib/zmq.cs#L28 > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > https://github.com/zeromq/pyczmq/blob/master/pyczmq/zmq.py#L > >> > > >> >> > >>> 177 > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > Other bindings just import zmq.h. Did I miss any? > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > >> Sorry for disappearing, baby and full time job > >> > > >> >> > >>> > >>> > >> is a > >> > > >> >> > >>> > >>> > >> lot > >> > > >> >> > >>> > >>> > >> :-), > >> > > >> >> > >>> > >>> hopefully > >> > > >> >> > >>> > >>> > >> I'm back... > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > > No worries, perfectly understandable :-) > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > >> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi < > >> > > >> >> > >>> > >>> luca.bocca...@gmail.com> wrote: > >> > > >> >> > >>> > >>> > >> > Sorry, I meant if we go with (1), not (2), we > >> > > >> >> > >>> > >>> > >> > might > >> > > >> >> > >>> > >>> > >> > bump > >> > > >> >> > >>> the size > >> > > >> >> > >>> > >>> as > >> > > >> >> > >>> > >>> > >> > well, since we are already doing another > >> > > >> >> > >>> > >>> > >> > ABI-breaking > >> > > >> >> > >>> change. > >> > > >> >> > >>> > >>> > >> > > >> > > >> >> > >>> > >>> > >> > I agree on the solution as well. > >> > > >> >> > >>> > >>> > >> > > >> > > >> >> > >>> > >>> > >> > On Mon, 2016-08-29 at 17:12 +0200, Pieter > >> > > >> >> > >>> > >>> > >> > Hintjens > >> > > >> >> > >>> > >>> > >> > wrote: > >> > > >> >> > >>> > >>> > >> >> I'm confused between the (1) and (2) > >> > > >> >> > >>> > >>> > >> >> choices, and > >> > > >> >> > >>> > >>> > >> >> can't > >> > > >> >> > >>> see where > >> > > >> >> > >>> > >>> > >> >> bumping the message size fits. > >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> Nonetheless, I think bumping the size, > >> > > >> >> > >>> > >>> > >> >> fixing the > >> > > >> >> > >>> > >>> > >> >> alignment > >> > > >> >> > >>> > >>> issues, > >> > > >> >> > >>> > >>> > >> >> and bumping the ABI version is the best > >> > > >> >> > >>> > >>> > >> >> solution > >> > > >> >> > >>> > >>> > >> >> here. > >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> On Fri, Aug 26, 2016 at 12:33 PM, Luca > >> > > >> >> > >>> > >>> > >> >> Boccassi < > >> > > >> >> > >>> > >>> luca.bocca...@gmail.com> wrote: > >> > > >> >> > >>> > >>> > >> >> > I've given some more thoughts and testing > >> > > >> >> > >>> > >>> > >> >> > to the > >> > > >> >> > >>> alignment > >> > > >> >> > >>> > >>> issue. I can > >> > > >> >> > >>> > >>> > >> >> > reproduce the problem by enabling alignment > >> > > >> >> > >>> > >>> > >> >> > checks > >> > > >> >> > >>> > >>> > >> >> > on > >> > > >> >> > >>> x86 too. > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > But most importantly, I think we cannot > >> > > >> >> > >>> > >>> > >> >> > get away > >> > > >> >> > >>> > >>> > >> >> > from > >> > > >> >> > >>> bumping > >> > > >> >> > >>> > >>> the ABI > >> > > >> >> > >>> > >>> > >> >> > with this fix, however we rearrange it, > >> > > >> >> > >>> > >>> > >> >> > simply > >> > > >> >> > >>> > >>> > >> >> > because > >> > > >> >> > >>> > >>> applications need > >> > > >> >> > >>> > >>> > >> >> > to be rebuilt against the new header to be > >> > > >> >> > >>> > >>> > >> >> > fixed. > >> > > >> >> > >>> > >>> > >> >> > A > >> > > >> >> > >>> simple > >> > > >> >> > >>> > >>> rebuild of > >> > > >> >> > >>> > >>> > >> >> > the libzmq.so is not enough. And the way > >> > > >> >> > >>> > >>> > >> >> > to do > >> > > >> >> > >>> > >>> > >> >> > this > >> > > >> >> > >>> > >>> > >> >> > is > >> > > >> >> > >>> to bump > >> > > >> >> > >>> > >>> the ABI > >> > > >> >> > >>> > >>> > >> >> > so that distros can schedule transitions > >> > > >> >> > >>> > >>> > >> >> > and > >> > > >> >> > >>> > >>> > >> >> > rebuilds > >> > > >> >> > >>> and so > >> > > >> >> > >>> > >>> on. > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > So the choice list is now restricted to: > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > 1) Bump ABI > >> > > >> >> > >>> > >>> > >> >> > 2) Revert the fix and leave everything > >> > > >> >> > >>> > >>> > >> >> > broken on > >> > > >> >> > >>> > >>> > >> >> > sparc64 > >> > > >> >> > >>> and > >> > > >> >> > >>> > >>> some > >> > > >> >> > >>> > >>> > >> >> > aarch64 (rpi3 seems not to be affected, > >> > > >> >> > >>> > >>> > >> >> > must > >> > > >> >> > >>> > >>> > >> >> > depend > >> > > >> >> > >>> > >>> > >> >> > on > >> > > >> >> > >>> the SoC > >> > > >> >> > >>> > >>> flavour) > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > If we go with 2, we might as well get 2 > >> > > >> >> > >>> > >>> > >> >> > birds > >> > > >> >> > >>> > >>> > >> >> > with > >> > > >> >> > >>> > >>> > >> >> > one > >> > > >> >> > >>> stone > >> > > >> >> > >>> > >>> and bump > >> > > >> >> > >>> > >>> > >> >> > the zmq_msg_t size to 128 as we have > >> > > >> >> > >>> > >>> > >> >> > talked about > >> > > >> >> > >>> > >>> > >> >> > in > >> > > >> >> > >>> > >>> > >> >> > the > >> > > >> >> > >>> past. > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > Doron, this would help with the new UDP > >> > > >> >> > >>> > >>> > >> >> > based > >> > > >> >> > >>> > >>> > >> >> > socket > >> > > >> >> > >>> types > >> > > >> >> > >>> > >>> right? > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > Pros of bumping msg size: > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > - we can get rid of the malloc() in the > >> > > >> >> > >>> > >>> > >> >> > lmsg type > >> > > >> >> > >>> > >>> > >> >> > case > >> > > >> >> > >>> as all > >> > > >> >> > >>> > >>> the data > >> > > >> >> > >>> > >>> > >> >> > will fit > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > Cons: > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > - for the vsm/cmsg type cases (for most > >> > > >> >> > >>> > >>> > >> >> > architectures > >> > > >> >> > >>> anyway) > >> > > >> >> > >>> > >>> it won't > >> > > >> >> > >>> > >>> > >> >> > fit anymore into a single cacheline > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > Given all this, I'd say we should go for > >> > > >> >> > >>> > >>> > >> >> > it. > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > Opinions? > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > On Sat, 2016-08-13 at 16:59 +0100, Luca > >> > > >> >> > >>> > >>> > >> >> > Boccassi > >> > > >> >> > >>> > >>> > >> >> > wrote: > >> > > >> >> > >>> > >>> > >> >> >> Hello, > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> Trying to give some thoughts again on the > >> > > >> >> > >>> > >>> > >> >> >> libzmq > >> > > >> >> > >>> > >>> > >> >> >> 4.2 > >> > > >> >> > >>> release. > >> > > >> >> > >>> > >>> It's > >> > > >> >> > >>> > >>> > >> >> >> really long overdue! > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> The main issue from my point of view is > >> > > >> >> > >>> > >>> > >> >> >> this > >> > > >> >> > >>> > >>> > >> >> >> change: > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> https://github.com/zeromq/libzmq/commit/ > >> > > >> >> > >>> > >>> d9fb1d36ff2008966af538f722a1f4ab158dbf64 > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> -typedef struct zmq_msg_t {unsigned char _ > >> > > >> >> > >>> > >>> > >> >> >> [64];} > >> > > >> >> > >>> zmq_msg_t; > >> > > >> >> > >>> > >>> > >> >> >> +/* union here ensures correct alignment > >> > > >> >> > >>> > >>> > >> >> >> on > >> > > >> >> > >>> architectures > >> > > >> >> > >>> > >>> that require > >> > > >> >> > >>> > >>> > >> >> >> it, e.g. > >> > > >> >> > >>> > >>> > >> >> >> + * SPARC > >> > > >> >> > >>> > >>> > >> >> >> + */ > >> > > >> >> > >>> > >>> > >> >> >> +typedef union zmq_msg_t {unsigned char > >> > > >> >> > >>> > >>> > >> >> >> _ [64]; > >> > > >> >> > >>> > >>> > >> >> >> void > >> > > >> >> > >>> *p; } > >> > > >> >> > >>> > >>> zmq_msg_t; > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> This is flagged by the common ABI > >> > > >> >> > >>> > >>> > >> >> >> checkers tools > >> > > >> >> > >>> > >>> > >> >> >> as > >> > > >> >> > >>> > >>> > >> >> >> an > >> > > >> >> > >>> ABI > >> > > >> >> > >>> > >>> breakage > >> > > >> >> > >>> > >>> > >> >> >> (see: http://abi-laboratory.pro/trac > >> > > >> >> > >>> ker/timeline/zeromq/ ). > >> > > >> >> > >>> > >>> And it makes > >> > > >> >> > >>> > >>> > >> >> >> sense from this point of view: if some > >> > > >> >> > >>> > >>> > >> >> >> applications > >> > > >> >> > >>> > >>> > >> >> >> on > >> > > >> >> > >>> some > >> > > >> >> > >>> > >>> > >> >> >> architectures are broken due to wrong > >> > > >> >> > >>> > >>> > >> >> >> alignment, > >> > > >> >> > >>> > >>> > >> >> >> they > >> > > >> >> > >>> would > >> > > >> >> > >>> > >>> need to be > >> > > >> >> > >>> > >>> > >> >> >> rebuilt, and the way to ensure that is to > >> > > >> >> > >>> > >>> > >> >> >> bump > >> > > >> >> > >>> > >>> > >> >> >> the > >> > > >> >> > >>> > >>> > >> >> >> ABI > >> > > >> >> > >>> > >>> "current" digit > >> > > >> >> > >>> > >>> > >> >> >> to make sure maintainers do a rebuild. > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> On the other hand, signaling an ABI > >> > > >> >> > >>> > >>> > >> >> >> breakage is > >> > > >> >> > >>> > >>> > >> >> >> a > >> > > >> >> > >>> > >>> > >> >> >> pain, > >> > > >> >> > >>> and a > >> > > >> >> > >>> > >>> cause of > >> > > >> >> > >>> > >>> > >> >> >> major churn for packagers and > >> > > >> >> > >>> > >>> > >> >> >> maintainers. It > >> > > >> >> > >>> > >>> > >> >> >> means > >> > > >> >> > >>> > >>> > >> >> >> for > >> > > >> >> > >>> > >>> example a new > >> > > >> >> > >>> > >>> > >> >> >> package has to be created (eg: libzmq5 -> > >> > > >> >> > >>> > >>> > >> >> >> libzmq6), > >> > > >> >> > >>> > >>> > >> >> >> and > >> > > >> >> > >>> a > >> > > >> >> > >>> > >>> transition has > >> > > >> >> > >>> > >>> > >> >> >> to be started and all reverse > >> > > >> >> > >>> > >>> > >> >> >> dependencies need > >> > > >> >> > >>> > >>> > >> >> >> to > >> > > >> >> > >>> > >>> > >> >> >> be > >> > > >> >> > >>> > >>> rebuilt. And if > >> > > >> >> > >>> > >>> > >> >> >> this is pointless for all save a few > >> > > >> >> > >>> > >>> > >> >> >> corner > >> > > >> >> > >>> > >>> > >> >> >> cases > >> > > >> >> > >>> > >>> > >> >> >> (eg > >> > > >> >> > >>> SPARC64 > >> > > >> >> > >>> > >>> as for > >> > > >> >> > >>> > >>> > >> >> >> above) it's all quite frustrating. > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> So we have a choice to make before we > >> > > >> >> > >>> > >>> > >> >> >> release > >> > > >> >> > >>> > >>> > >> >> >> 4.2, > >> > > >> >> > >>> > >>> > >> >> >> four > >> > > >> >> > >>> > >>> possibilities as > >> > > >> >> > >>> > >>> > >> >> >> far as I can see: > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> 1) Ignore the ABI checkers and get yelled > >> > > >> >> > >>> > >>> > >> >> >> at by > >> > > >> >> > >>> maintainers > >> > > >> >> > >>> > >>> and > >> > > >> >> > >>> > >>> > >> >> >> packagers. Also the SPARC64 users will > >> > > >> >> > >>> > >>> > >> >> >> most > >> > > >> >> > >>> > >>> > >> >> >> likely > >> > > >> >> > >>> > >>> > >> >> >> NOT > >> > > >> >> > >>> get > >> > > >> >> > >>> > >>> their bug > >> > > >> >> > >>> > >>> > >> >> >> fixed > >> > > >> >> > >>> > >>> > >> >> >> 2) Bump ABI revision to 6 and get yelled > >> > > >> >> > >>> > >>> > >> >> >> at by > >> > > >> >> > >>> maintainers > >> > > >> >> > >>> > >>> and packagers > >> > > >> >> > >>> > >>> > >> >> >> 3) Revert the above change and postpone > >> > > >> >> > >>> > >>> > >> >> >> it to > >> > > >> >> > >>> > >>> > >> >> >> when > >> > > >> >> > >>> > >>> > >> >> >> we > >> > > >> >> > >>> have a > >> > > >> >> > >>> > >>> more > >> > > >> >> > >>> > >>> > >> >> >> generally useful reason to break ABI (bump > >> > > >> >> > >>> > >>> > >> >> >> zmq_msg_t > >> > > >> >> > >>> from 64 > >> > > >> >> > >>> > >>> to 128 > >> > > >> >> > >>> > >>> > >> >> >> bytes for example, Doron?) > >> > > >> >> > >>> > >>> > >> >> >> 4) Try to be clever and revert the above > >> > > >> >> > >>> > >>> > >> >> >> change > >> > > >> >> > >>> > >>> > >> >> >> and > >> > > >> >> > >>> > >>> > >> >> >> use > >> > > >> >> > >>> > >>> something like > >> > > >> >> > >>> > >>> > >> >> >> #pragma pack(8). This will fool the ABI > >> > > >> >> > >>> > >>> > >> >> >> checkers > >> > > >> >> > >>> > >>> > >> >> >> (I > >> > > >> >> > >>> tried > >> > > >> >> > >>> > >>> it), and given > >> > > >> >> > >>> > >>> > >> >> >> that typedef is only used externally to > >> > > >> >> > >>> > >>> > >> >> >> allocate > >> > > >> >> > >>> > >>> > >> >> >> the > >> > > >> >> > >>> right > >> > > >> >> > >>> > >>> size it > >> > > >> >> > >>> > >>> > >> >> >> shouldn't actually affect anything, apart > >> > > >> >> > >>> > >>> > >> >> >> from > >> > > >> >> > >>> > >>> > >> >> >> the > >> > > >> >> > >>> users of > >> > > >> >> > >>> > >>> SPARC64 > >> > > >> >> > >>> > >>> > >> >> >> which should get the bugfix with this > >> > > >> >> > >>> > >>> > >> >> >> too. This > >> > > >> >> > >>> > >>> > >> >> >> is > >> > > >> >> > >>> > >>> > >> >> >> very > >> > > >> >> > >>> > >>> sneaky :-) > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> CC'ing Lazslo, the Debian maintainer, > >> > > >> >> > >>> > >>> > >> >> >> given what > >> > > >> >> > >>> > >>> > >> >> >> we > >> > > >> >> > >>> choose to > >> > > >> >> > >>> > >>> do might > >> > > >> >> > >>> > >>> > >> >> >> result in a lot of work for him :-) > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> Opinions? > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> Kind regards, > >> > > >> >> > >>> > >>> > >> >> >> Luca Boccassi > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> On Tue, 2016-05-03 at 10:39 +0200, Pieter > >> > > >> >> > >>> > >>> > >> >> >> Hintjens > >> > > >> >> > >>> wrote: > >> > > >> >> > >>> > >>> > >> >> >> > Hi all, > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > I'm just throwing some ideas on the > >> > > >> >> > >>> > >>> > >> >> >> > table. We > >> > > >> >> > >>> > >>> > >> >> >> > have a > >> > > >> >> > >>> good > >> > > >> >> > >>> > >>> package of > >> > > >> >> > >>> > >>> > >> >> >> > work on master and it's probably time > >> > > >> >> > >>> > >>> > >> >> >> > to make > >> > > >> >> > >>> > >>> > >> >> >> > a > >> > > >> >> > >>> > >>> > >> >> >> > 4.2 > >> > > >> >> > >>> release. > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > Luca has already back-ported the > >> > > >> >> > >>> > >>> > >> >> >> > enable/disable > >> > > >> >> > >>> > >>> > >> >> >> > draft > >> > > >> >> > >>> > >>> design from > >> > > >> >> > >>> > >>> > >> >> >> > zproject (CZMQ et al). Yay! So we can > >> > > >> >> > >>> > >>> > >> >> >> > now > >> > > >> >> > >>> > >>> > >> >> >> > release > >> > > >> >> > >>> stable > >> > > >> >> > >>> > >>> master > >> > > >> >> > >>> > >>> > >> >> >> > safely, while continuing to refine and > >> > > >> >> > >>> > >>> > >> >> >> > extend > >> > > >> >> > >>> > >>> > >> >> >> > the > >> > > >> >> > >>> draft API > >> > > >> >> > >>> > >>> sections. > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > I propose: > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > - to end with the stable fork policy; > >> > > >> >> > >>> > >>> > >> >> >> > this was > >> > > >> >> > >>> > >>> > >> >> >> > needed > >> > > >> >> > >>> years > >> > > >> >> > >>> > >>> ago when > >> > > >> >> > >>> > >>> > >> >> >> > we had massively unstable masters. It's > >> > > >> >> > >>> > >>> > >> >> >> > no > >> > > >> >> > >>> > >>> > >> >> >> > longer > >> > > >> >> > >>> > >>> > >> >> >> > a > >> > > >> >> > >>> problem. > >> > > >> >> > >>> > >>> > >> >> >> > - to use the github release function for > >> > > >> >> > >>> > >>> > >> >> >> > libzmq > >> > > >> >> > >>> releases > >> > > >> >> > >>> > >>> and deprecate > >> > > >> >> > >>> > >>> > >> >> >> > the separate delivery of tarballs. > >> > > >> >> > >>> > >>> > >> >> >> > - we aim to make a 4.2.0 rc asap, then > >> > > >> >> > >>> > >>> > >> >> >> > fix any > >> > > >> >> > >>> > >>> > >> >> >> > issues > >> > > >> >> > >>> we > >> > > >> >> > >>> > >>> get, with > >> > > >> >> > >>> > >>> > >> >> >> > patch releases as usual. > >> > > >> >> > >>> > >>> > >> >> >> > - we backport the release function to > >> > > >> >> > >>> > >>> > >> >> >> > older > >> > > >> >> > >>> > >>> > >> >> >> > maintained > >> > > >> >> > >>> > >>> releases (4.1, > >> > > >> >> > >>> > >>> > >> >> >> > 3.2) so that their tarballs are > >> > > >> >> > >>> > >>> > >> >> >> > provided by > >> > > >> >> > >>> > >>> > >> >> >> > github > >> > > >> >> > >>> instead > >> > > >> >> > >>> > >>> of > >> > > >> >> > >>> > >>> > >> >> >> > downloads.zeromq.org. > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > Problems: > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > - this will break a few things that > >> > > >> >> > >>> > >>> > >> >> >> > depend on > >> > > >> >> > >>> > >>> downloads.zeromq.org. To > >> > > >> >> > >>> > >>> > >> >> >> > be fixed as we go. > >> > > >> >> > >>> > >>> > >> >> >> > - github tarballs are not identical to > >> > > >> >> > >>> > >>> > >> >> >> > source > >> > > >> >> > >>> tarballs, > >> > > >> >> > >>> > >>> particularly > >> > > >> >> > >>> > >>> > >> >> >> > they lack `configure`. I propose > >> > > >> >> > >>> > >>> > >> >> >> > changing our > >> > > >> >> > >>> autotools > >> > > >> >> > >>> > >>> build > >> > > >> >> > >>> > >>> > >> >> >> > instructions so they always start with > >> > > >> >> > >>> > >>> > >> >> >> > `./autogen,sh` > >> > > >> >> > >>> no > >> > > >> >> > >>> > >>> matter where > >> > > >> >> > >>> > >>> > >> >> >> > the sources come from. > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > I think this will work and also let us > >> > > >> >> > >>> > >>> > >> >> >> > gracefully > >> > > >> >> > >>> > >>> deprecate/switch off > >> > > >> >> > >>> > >>> > >> >> >> > the downloads box. > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > -Pieter > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > _______________________________________________ > >> > > >> >> > >>> > >>> > >> >> >> > zeromq-dev mailing list > >> > > >> >> > >>> > >>> > >> >> >> > zeromq-dev@lists.zeromq.org > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > > >> > > >> >> > >>> > >>> > >> >> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > _______________________________________________ > >> > > >> >> > >>> > >>> > >> >> > zeromq-dev mailing list > >> > > >> >> > >>> > >>> > >> >> > zeromq-dev@lists.zeromq.org > >> > > >> >> > >>> > >>> > >> >> > > >> > > >> >> > >>> > >>> > >> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > >> >> > >>> > >>> > >> >> _______________________________________________ > >> > > >> >> > >>> > >>> > >> >> zeromq-dev mailing list > >> > > >> >> > >>> > >>> > >> >> zeromq-dev@lists.zeromq.org > >> > > >> >> > >>> > >>> > >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > >> >> > >>> > >>> > >> > > >> > > >> >> > >>> > >>> > >> > > >> > > >> >> > >>> > >>> > > > >> > > >> >> > >>> > >>> > >> > > >> >> > >>> > >>> _______________________________________________ > >> > > >> >> > >>> > >> zeromq-dev mailing list > >> > > >> >> > >>> > >> zeromq-dev@lists.zeromq.org > >> > > >> >> > >>> > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > >> >> > >>> > > > >> > > >> >> > >>> > > > >> > > >> >> > >>> > _______________________________________________ > >> > > >> >> > >>> > zeromq-dev mailing list > >> > > >> >> > >>> > zeromq-dev@lists.zeromq.org > >> > > >> >> > >>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > >> >> > >>> > >> > > >> >> > >>> > >> > > >> >> > >>> > >> > > >> >> > >> > > >> >> > >> > > >> > > >> > > >> > > >> > >> > > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > zeromq-dev@lists.zeromq.org > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
