Pieter - successfully sent syslog traffic over udp multicast via zeromq this week, using RADIO / DISH ;)
On Tue, May 3, 2016 at 2:08 PM Pieter Hintjens <[email protected]> wrote: > Wow... :) > > On Tue, May 3, 2016 at 7:36 PM, Brian Knox <[email protected]> wrote: > > As a heads up I'm adding support for RADIO / DISH, SCATTER / GATHER and > > CLIENT / SERVER to rsyslog for the 8.19 release later this month. The > code > > will be wrapped with define checks so keep it safe to compile against > CZMQ > > stable. If these are still considered draft and won't be built by > default > > that's fine, I manage our zeromq / czmq packages and have custom ones > > anyway. > > > > Brian > > > > On Tue, May 3, 2016 at 8:13 AM Luca Boccassi <[email protected]> > > wrote: > >> > >> 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. > >> > >> :-) > >> > >> Is any of the API I marked as draft actually ready for release? > >> > >> > 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. > >> > >> I like not using forks anymore, as having a separate git history is a > >> pain for backporting fixes. > >> So should we use branches instead for bugfix releases? > >> > >> > - 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. > >> > >> The problem is that will add all the autotools chain as a > >> build-dependency. And given that the end result varies massively > >> depending on version and platform, this might create more issues for > >> users. > >> > >> Isn't it possible to do the github release thing with the result of > >> "make dist"? I think I've read somewhere that you can use the result of > >> CI builds. If that's the case, we can still use the make dist release > >> tarballs IMHO. > >> > >> Kind regards, > >> Luca Boccassi > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
