IRC Log

Saturday April 2, 2011

[Time] NameMessage
[03:10] seangrove Hey all, I've been through most of the guide, but happy if someone can point me out how to handle async stuff with 0mq in ruby?
[03:12] seangrove Ah, I think I misunderstood, there's no callback pattern
[03:16] seangrove I think the main problem now is that I can't get my program to quit without using ctrl+c
[03:17] fatpelt_laptop evenin all! just found you through a friend and we are currently playing around with the library. am i understanding this right that zmq_bind() can't take an ipv6 address?
[03:44] seangrove Hmm, seems like zeromq and rails don't go together
[04:17] fatpelt_laptop ah found it. tcp_listener.cpp has v4 hardcoded in it :(
[04:18] fatpelt_laptop er.. i mean ip.cpp:resolve_ip_interface() (missed a breakpoint there)
[05:06] sustrik fatpelt_laptop: there was ipv6 support once
[05:07] sustrik but it collided with ipv4 in some cases
[05:07] sustrik thus it was taken out
[05:07] sustrik do you need ipv6 specifically?
[05:08] fatpelt_laptop sustrik: we are looking at possibly using zmq in our app (www.bongo-project.org). i'd like v6 yes. is it required? technically no
[05:08] fatpelt_laptop right now we have our own threading and network io model
[05:09] sustrik it would be nice is someone would look at the ipv6 code
[05:09] sustrik as i said, it used to be there
[05:09] sustrik but had to be disabled
[05:09] sustrik so if there's a real user, the things can be presumably sorted out
[05:10] fatpelt_laptop hmm. do you know exactly how it collided?
[05:10] fatpelt_laptop seems straightforward to modify that cpp file to support v6
[05:11] sustrik iirc the problem was with dual stack
[05:11] fatpelt_laptop one other question, (i'm not too far down the guide yet), could we tie gnutls in here?
[05:11] sustrik in short, in some cases 0mq was using ipv6 interface where in fact user wanted to use ipv4 one
[05:12] sustrik i think the problem was in how interface names were resolved
[05:12] fatpelt_laptop hmm. isn't that an issue for the ipv6 preference? http://linux.die.net/man/5/gai.conf
[05:12] fatpelt_laptop ah, but...
[05:12] sustrik dunno. people reported "0mq not working"
[05:13] fatpelt_laptop if you were to say, bind to <interfacename> the loop in resolve_nic (or whatever that func was) might return the v6 nic first
[05:13] sustrik yes, i think that was the problem
[05:13] fatpelt_laptop i'll bet that was the issue
[05:13] sustrik any idea about how to solve it?
[05:14] sustrik if so, i would send a suggestion to the mailing list, where other folks with ipv6 experience can comment
[05:14] fatpelt_laptop i grok'd the code fully there.... so this might be wrong. either modify the code to pass in the address family or create a tcp6://
[05:14] sustrik that way the ipv6 stuff could be solved pretty quickly
[05:15] sustrik no opaque way to deal with that?
[05:15] fatpelt_laptop er.. that should be i haven't grok'd the code
[05:15] sustrik the code isn't that importatnt, the question is rather "how it SHOULD work?"
[05:16] fatpelt_laptop i don't see how you could do that. gai.conf only applies to getaddrinfo() which isn't used here (unless the user added a host entry with their nic name)
[05:16] sustrik can you possibly comment on that on the mailing list?
[05:16] sustrik i would like to see the issue discussed
[05:16] fatpelt_laptop hmm. wait...
[05:17] fatpelt_laptop oh hai.
[05:18] fatpelt_laptop ip.cpp:149 has == AF_INET. what if that was changed to addr_.ai_family
[05:18] sustrik let me see
[05:18] fatpelt_laptop my failing here is that i've got *very* limited exp with this on other platforms so i dunno if that works everywhere. perhaps i'll try patching it
[05:20] fatpelt_laptop ah that won't work
[05:20] sustrik the problem is that family is not passed to zmq_connect or zmq_bind
[05:20] sustrik so it has to be either deduced or specified explicitly
[05:20] sustrik i don't know whether the former is feasible
[05:21] fatpelt_laptop yeah, i'm not sure it can either
[05:21] sustrik that's why discussion of the issue would be good
[05:21] sustrik before doing any implementation work
[05:21] fatpelt_laptop so i take it then that there a a lot of people use the interface name over an ip or anything
[05:21] sustrik i think so
[05:21] sustrik haven't done any survey though
[05:22] fatpelt_laptop sometimes i wish that c supported cool default params on function calls....
[05:22] sustrik maybe just enhancing the iface name would do?
[05:23] sustrik tcp://eth0/6:5555
[05:23] fatpelt_laptop can we guarantee that an interface name can't have a / in it?
[05:23] sustrik no idea
[05:24] sustrik fwiw i am not sure whether we can guarantee there's no : in the iface name
[05:24] fatpelt_laptop old school secondary ips on linux had :
[05:24] sustrik which would break in the current implementation...
[05:25] sustrik however, the parsing can be changed
[05:25] sustrik "find *last* colon in the connection string"
[05:25] sustrik and "find last slash before the last colon"
[05:25] fatpelt_laptop http://slexy.org/view/s2VJpj41lr
[05:26] sustrik ack
[05:26] fatpelt_laptop internal/2 did not work. should posted that command as well
[05:27] sustrik anyway, if you are interested in ipv6 functionality, just post a note on the mailing list and see whether people catch on
[05:28] sustrik as for tls, there were some people speaking about it, but nodoby implemented it afaik yet
[05:29] fatpelt_laptop so far in my reading seems like that one is a bit hairy in the current code
[05:29] sustrik tls?
[05:29] fatpelt_laptop yeah
[05:30] sustrik what's the API?
[05:30] fatpelt_laptop we are currently using gnutls
[05:30] sustrik standard BSD sockets?
[05:30] fatpelt_laptop but openssl supports it too
[05:30] fatpelt_laptop basically in gnutls you create a crypto context and bind an FD to it
[05:30] fatpelt_laptop then call gnutls_record_recv() (if i remember that function call correctly)
[05:31] fatpelt_laptop and currently we have to keep track if tls is enabled so we call that over the normal recv()
[05:31] sustrik ok, then is should not be that complex
[05:31] fatpelt_laptop well we'd have to change tcp_socket_t::read()
[05:32] fatpelt_laptop or have a tls_socket_t class
[05:32] sustrik or a flag
[05:32] sustrik implementing 0mq over unix domain sockets was kind of similar
[05:32] sustrik i recall someone have done it in matter of days
[05:33] fatpelt_laptop how many devs are there on 0mq ?
[05:33] sustrik it's a community project
[05:33] fatpelt_laptop yeah
[05:33] fatpelt_laptop just curious as to how many active devs were around
[05:33] sustrik authors file lists 59
[05:33] fatpelt_laptop (bongo we've only got two for the c code)
[05:33] sustrik but not of them are active of course
[05:33] fatpelt_laptop which makes it hard
[05:34] sustrik i would really recommend discussing it on the mailing list
[05:34] sustrik you may spark interest in the question
[05:34] sustrik and someone else may implement it :)
[05:34] fatpelt_laptop hehe
[05:35] fatpelt_laptop i was looking at adding it to our socket library
[05:35] fatpelt_laptop but if we go with 0mq that'll all go away i believe
[05:36] sustrik presumably
[05:36] sustrik additional benefit being is that the community will maintain your code afterwards
[05:37] fatpelt_laptop another benefit, i'll have to brush off my cpp. it's been a long while
[05:37] sustrik :)
[05:42] fatpelt_laptop i'll read the guide then i'll likely post to -dev
[05:42] fatpelt_laptop but i'd like to get my terminology *semi* right first....
[05:49] sustrik see you
[06:05] CIA-22 zeromq2: 03Martin Sustrik 07pre30 * r54830ac 10/ (builds/msvc/libzmq/libzmq.vcproj builds/msvc/msvc.sln):
[06:05] CIA-22 zeromq2: MSVC build system updated to match 3.0 changes
[06:05] CIA-22 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/enBrlt
[06:51] CIA-22 zeromq2: 03Martin Sustrik 07pre30 * r85c2a84 10/ (5 files in 4 dirs):
[06:51] CIA-22 zeromq2: inproc perf tests now work on Windows
[06:51] CIA-22 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/ePx6EE
[07:24] CIA-22 zeromq2: 03Pieter Hintjens 07pre30 * r3e65522 10/ src/thread.cpp :
[07:24] CIA-22 zeromq2: Fixed memory leak with threads on win32
[07:24] CIA-22 zeromq2: Signed-off-by: Pieter Hintjens <ph@imatix.com> - http://bit.ly/fnU3WV
[07:27] sustrik mikko: hi
[07:27] sustrik are you there?
[09:13] pieterh sustrik: hi
[12:49] cremes seangrove: what do you mean about rails and 0mq? if you have errors you should pastie them or
[12:49] cremes open a ticket
[16:03] mikko sustrik: am now
[16:05] sustrik mikko: hi
[16:05] sustrik what about doing the reanme?
[16:05] sustrik rename*
[16:05] mikko you wanna do it today or tomorrow?
[16:05] sustrik up to you
[16:05] sustrik i am free both days
[16:06] mikko do we know everything we need to update during the rename?
[16:06] sustrik my idea is:
[16:07] sustrik 1. i raname the repo
[16:07] sustrik 2. you fix the build system
[16:07] sustrik 3. i fix the website
[16:07] sustrik there's still peter alexander's doxygen thing, but he haven't commented
[16:07] sustrik so i would just ignore it for now
[16:08] pieterh sustrik: mikko: I'd really recommend alerting the list beforehand
[16:08] sustrik rather than afterwards?
[16:08] pieterh well, there are other people affected, so yes
[16:08] sustrik ok
[16:09] pieterh I'd recommend tomorrow morning early, gives us time to patch everything up
[16:09] pieterh but please announce a time in advance...
[16:09] sustrik what exactly needs to be patched?
[16:09] sustrik i mean aside of build system and the site
[16:09] pieterh for one thing, there are several links on the zeromq.org site
[16:10] sustrik yeah, i change that
[16:10] mikko build system should be just "sed -i 's~git://github.com/zeromq/zeromq2.git~git://github.com/zeromq/libzmq.git~g' */config.xml" and restart
[16:10] mikko but let me put backups running just in case
[16:10] pieterh sustrik: your commits today, will you send me the ones I can downstream?
[16:11] pieterh & those last night
[16:11] sustrik pieterh: yes
[16:11] sustrik when i get them to the trunk
[16:11] sustrik i.e. after the reanme
[16:11] sustrik rename*
[16:11] pieterh thanks... note also we can put new stuff into 2.2, even if not fully tested
[16:11] sustrik ok
[16:11] sustrik mikko: ping me when you want me to rename the repo
[16:12] pieterh sustrik: I'll make a list of all pages I can find with the git URI
[16:12] sustrik 3 of them
[16:13] sustrik pieterh: you may want to check all those extra sites of yours
[16:13] pieterh sustrik: yes, indeed
[16:14] mikko sustrik: can we do it after the builds finish?
[16:14] pieterh lol, wikidot's search functionality actually does work...
[16:14] mikko the 17:00 builds just started
[16:15] mikko in about two hours?
[16:15] pieterh sustrik: http://www.wikidot.com/search:all/a/pf/q/zeromq2 :-)
[16:16] pieterh mikko: is it a good idea to make this change in the evening? people are more active than in the morning
[16:17] mikko i'm flexible
[16:17] mikko has anyone asked if github can redirect?
[16:17] pieterh they don't
[16:18] sustrik pieterh: it's saturday evening, nobody cares imo
[16:18] pieterh well, I'm sure they could, but they explicitly say "we don't do redirects" when you do a rename
[16:18] pieterh sustrik: saturday afternoon in the USA...
[16:18] sustrik spring...
[16:18] pieterh hmm, true
[16:18] sustrik people outside, jogging
[16:18] pieterh geeks? jogging?
[16:18] sustrik ehm
[16:18] sustrik being outside then
[16:19] pieterh you mean where there's wifi?
[16:19] sustrik that should do
[16:19] pieterh why would anyone go outside?
[16:19] sustrik isn't in spring in bxl?
[16:20] sustrik here it's like 20`C
[16:20] sustrik sunny
[16:20] pieterh the sun makes it hard to read my notebook screen...
[16:20] sustrik anyway, let's do it
[16:20] pieterh well, Sunday and Saturday are both off-peak, it's moot
[16:20] pieterh I'd just recommend emailing the list in advance so people can't complain they weren't warned
[16:21] pieterh maintenance should be scheduled
[16:23] sustrik mikko: done
[16:23] sustrik here you go
[16:23] mikko ok
[16:25] mikko builds updated, reloading config now
[16:28] pieterh sigh... sustrik: that sucks, sorry
[16:29] sustrik ?
[16:29] pieterh you agreed a few days ago to warn the list
[16:29] sustrik i did
[16:30] pieterh in advance
[16:32] sustrik ok, website changed
[16:38] sustrik nice, even github network graph seems to work
[16:45] sustrik freshmeat updated
[16:46] sustrik pieterh: btw, freshmeat links point to 2.1.3 for the repo
[16:46] sustrik but issue tracker link points to master
[16:46] sustrik is that intended?
[16:46] pieterh sustrik: yes, that's right
[16:47] sustrik ah, 2.1 has issue tracker disabled?
[16:47] pieterh it was intended but now I think it's better to point to the libzmq git
[16:47] sustrik it's not disabled
[16:47] sustrik so what's the idea?
[16:47] pieterh well, we use it for internal patch tracking
[16:48] sustrik 2 issue trackers or one?
[16:48] sustrik ah
[16:48] pieterh one issue tracker, of course, for public use
[16:48] sustrik ok
[16:48] pieterh packaging project != library included in it
[16:49] pieterh where do you go log an openpgm issue?
[16:49] pieterh actually, anywhere you can :-)
[16:49] sustrik i send an email to steve...
[16:49] sustrik :)
[16:50] sustrik mikko: how it's going?
[16:50] pieterh well, my point is you'd not log an openpgm issue in the libzmq tracker
[16:51] sustrik people actually do, then it's kind of upstreamed to openpgm
[16:51] sustrik but there's no real process there
[16:51] pieterh yes, but it's not consistent
[16:51] pieterh consistency is, IMO, issues get tracked close to packaging
[16:51] pieterh not that I really want this
[16:52] pieterh but it's what you'd expect: you report an issue to the person who gave you the package
[16:52] pieterh that person reports it upstream, etc.
[16:52] sustrik yep, something like that
[16:52] pieterh I think this will become easier now with the new name
[16:59] sustrik travlr: hi
[17:00] mikko sustrik: should be done
[17:00] sustrik great!
[17:00] sustrik thanks for help!
[17:01] mikko np
[17:01] mikko i'll rename the builds at some point as well
[17:01] pieterh sustrik: ok, there's no way to make an html redirect, but I've made a map
[17:02] mikko is zeromq2-1 going to be libzmq2-1?
[17:02] pieterh mikko: no, libzmq is the library, zeromq is the package
[17:02] pieterh package = (libzmq, libpgm, libzapi, etc)
[17:03] sustrik you should package some bindings along with it
[17:03] sustrik people would love that
[17:03] pieterh yes, indeed
[17:03] pieterh the idea was to start with the simplest one, libzapi, since it already uses the same autotooling, and then add more bindings
[17:03] sustrik jzmq used to use autotools
[17:04] sustrik but that may have changed in the meantime
[17:04] pieterh sustrik: the map is at https://github.com/zeromq/zeromq2
[17:05] sustrik wouldn't it be better to just point to the website?
[17:05] sustrik the links will break gradually in the future
[17:05] pieterh "there's no way to make an html redirect, but I've made a map"
[17:05] sustrik i mean, there are pointers to 10 different projects in the map
[17:06] pieterh yes
[17:06] sustrik not likely to stay functional
[17:06] pieterh right now many of these projects don't have their own web sites or pages
[17:06] pieterh they should, then pages like this can be properly done
[17:06] sustrik why not just point to zero.mq
[17:06] sustrik or something
[17:07] sustrik "This is a deprecated project. Please check zero.mq for more info."
[17:07] pieterh because anyone coming here, looking for the repository, is going to be really confused (and annoyed) if they land on zero.mq instead
[17:07] pieterh "OMG 0MQ is deprecated!"
[17:07] pieterh the point is to assist people who land on the old URI
[17:07] pieterh placing libzmq in its context
[17:08] pieterh this page will be abandoned in a few weeks
[17:08] sustrik "Repo have been moved. Check github.com/zeromq/libzmq instead."
[17:08] sustrik ah, ok then
[17:08] pieterh well, that's what it says, doesn't it?
[17:08] sustrik don't forget to delete it afterwards
[17:09] pieterh this repository has no purpose except to help people who still use the old URI
[17:09] pieterh I'd like to put a map like this onto the community site as well
[17:09] pieterh but it requires more explicit and consistent visibility for each project
[17:34] sustrik CIA is broken
[17:34] sustrik mato has to fix that
[17:59] pieterh sustrik: those patches, which ones can go into 2.1 stable?
[18:00] pieterh I assume all except the 'project name change'?
[18:01] sustrik all of them i think
[18:01] sustrik the 'name change' changes README
[18:01] sustrik that points to zeromq2
[18:02] pieterh ah, ok... nice, thanks
[18:15] yrashk fixing totally broken erlzmq2
[18:17] yrashk was everything broken on purpose or is it 3.0 preparation?
[18:18] pieterh yrashk: 'totally broken' means what exactly?
[18:18] jond pieterh , sustrik: git pull is complaining for me now. I have a feeling this change could have been managed better
[18:18] yrashk well the API went south
[18:18] yrashk constants, different calls
[18:18] yrashk (master)
[18:18] pieterh yrashk: indeed, the API has changed in libzmq master
[18:19] pieterh jond: you'll need to change your remote
[18:19] yrashk so when do we need to start supporting it?
[18:19] pieterh yrashk: it's still unstable so up to you, really
[18:19] jond pieterh : i've done the commands from the email
[18:20] yrashk may be later in a branch, then
[18:20] pieterh jond: could you tell me what git complains about, then?
[18:20] pieterh yrashk: I'm going to support the 3.0 API in libzapi as soon as possible
[18:21] jond pieterh: this is what its saying .... jon@ubik:~/work/zeromq2$ git pull
[18:21] jond You asked me to pull without telling me which branch you
[18:21] jond want to merge with, and 'branch.master.merge' in
[18:21] jond your configuration file does not tell me either. Please
[18:21] jond specify which branch you want to merge on the command line and
[18:21] jond try again (e.g. 'git pull <repository> <refspec>').
[18:21] jond See git-pull(1) for details.
[18:21] jond If you often merge with the same branch, you may want to
[18:21] jond configure the following variables in your configuration
[18:21] jond file:
[18:21] jond branch.master.remote = <nickname>
[18:21] jond branch.master.merge = <remote-ref>
[18:21] jond remote.<nickname>.url = <url>
[18:21] jond remote.<nickname>.fetch = <refspec>
[18:21] jond See git-config(1) for details.
[18:21] pieterh git madness...
[18:21] pieterh what command were you using?
[18:21] jond pieterh: git pull
[18:21] pieterh there are defaults, I don't know how they work and never use them
[18:21] pieterh git pull origin master
[18:22] pieterh pulling the wrong branch by accident is traumatic
[18:22] jond pieterh: thx that appears to have worked
[18:22] pieterh goodo!
[18:23] jond pieter: but subsequent 'git pull' produce the same message. I never used to do this......
[18:24] pieterh jond: like I said, there are defaults, I don't use them, don't trust them.
[18:24] jond pieterh: life is too short i'll clone it
[18:24] pieterh indeed
[18:33] yrashk where did ZMQ_RECOVERY_IVL_MSEC/ZMQ_RECONNECT_IVL_MAX go in v2.1.0?
[18:34] sustrik there were not yet there back then iirc
[18:34] yrashk I am lost
[18:34] yrashk erlzmq2 already supported those
[18:34] yrashk :-\
[18:34] sustrik what's wrong with using 2.1.3?
[18:35] yrashk where's the tag for it?
[18:35] sustrik zeromq2-1 repo
[18:35] yrashk :-O
[18:35] mikko this is confusing for the end-users
[18:35] yrashk very
[18:36] sustrik yep, many changes at the same time
[18:36] yrashk multiple repos are baaaaad
[18:36] sustrik but still better than doing one change at a time
[18:36] yrashk :-(
[18:36] mikko i mean the whole multiple repos
[18:37] sustrik well, it's about process
[18:37] sustrik for 1 repo you need 1 process
[18:38] sustrik so people would have to agree on what the right process is
[18:38] yrashk what do you mean by process?
[18:38] yrashk what's wrong with branches?
[18:38] mikko sustrik: i disagree with this
[18:38] sustrik the set of rules to maintain the repo
[18:38] yrashk what's wrong with branches?
[18:38] mikko sustrik: for one logical entity you need a process
[18:38] mikko sustrik: that logical entity can live in the same repo
[18:39] sustrik you mean having different processes for different branches?
[18:39] mikko sustrik: the process would be no different if 2-1 was a branch
[18:39] mikko pieter would still merge changes from other branches
[18:39] sustrik yes, that's not the problem
[18:40] mikko sustrik: but it is
[18:40] sustrik ?
[18:40] mikko sustrik: currently people expect to find everything in libzmq repo
[18:40] mikko like tags, branches etc
[18:40] sustrik i am happy to host 2-1 stable in libzmq
[18:40] sustrik but then i want it to follow my process
[18:40] sustrik that's it
[18:41] mikko why does it have to if it doesn't touch your work at all?
[18:41] yrashk you can do this with a branch
[18:41] sustrik well, yes, that's the question
[18:41] sustrik is it ok to have separate processes for separate branches?
[18:41] yrashk sustrik: of course it is
[18:41] mikko my current thinking is the following:
[18:42] mikko i would be a lot happier if i had a branch / branches in libzmq repo
[18:42] sustrik like for branch X it's ok to break backward compatibility for minor version, while in branch Y it cannot happen?
[18:42] mikko that people can merge
[18:42] mikko sustrik: yes
[18:43] yrashk sustrik: totally fine
[18:43] jond mikko: i agree. the process and repos seem to be different to any other project , but i'm far from a git expert. but something instinctive tells me there has to be an easier way
[18:43] mikko i tend to find the mailing-list patches very tedious
[18:43] yrashk and MUCH less confusing than multiple repos
[18:43] mikko and they make things very hard to track on this side of the fence
[18:43] mikko having multiple patches "in-flight"
[18:44] pieterh it'd be nice to move the 2.1 branch back into libzmq and keep the distribution repo purely for packaging
[18:44] mikko pieterh: you can achieve this with submodules i believe
[18:44] pieterh sure, easy
[18:44] pieterh the real problem is as sustrik said, different processes within one repo
[18:44] mikko that way there are no copies
[18:44] mikko pieterh: why is this a problem?
[18:44] mikko pieterh: you have multiple branches
[18:44] pieterh well, it's been a big problem in the past
[18:45] pieterh agreed, we didn't have separate branches
[18:45] mikko there was master/maint in the past
[18:45] pieterh well, I see these specific issues:
[18:45] pieterh - single issue tracker
[18:45] pieterh - single set of pull requests
[18:46] mikko the issue tracker in github is not very good to be fair
[18:46] sustrik true
[18:46] pieterh but mikko, this would not solve the problem of applying patches to X versions
[18:46] sustrik and slow
[18:46] mikko but in normal cases you would select the version of the product
[18:46] pieterh it would not change anything, really
[18:46] mikko the single set of pull requests is ok imho
[18:46] pieterh take your latest three patches
[18:47] pieterh what's the process for applying these to 2.1, 2.2, and 3.0?
[18:47] mikko pieterh: how would it be nay different for you applying to a branch then a separate repo?
[18:47] pieterh mikko: that's six and half-a-dozen, for sure
[18:47] pieterh with the difference that working in one repo makes it easier to really mess up other peoples' work
[18:48] pieterh this is a real risk, especially for core projects
[18:49] mikko why is this a risk?
[18:49] pieterh people like me get distracted and make mistakes with git
[18:49] pieterh unrecoverable mistakes
[18:49] mikko the multiple repos seem to be about creating silos
[18:49] pieterh the more complex the repo, the more risk of error
[18:49] yrashk unrecoverable? how so?
[18:49] pieterh well, given sufficient git expertise, anything is recoverable
[18:49] pieterh I assume
[18:50] yrashk unless you do rm -rf when you're distracted
[18:50] yrashk but noting is going to help with that :-P
[18:50] mikko your process would be very much similar to what it is now
[18:50] mikko you would cherry pick changes as you do now
[18:50] pieterh mikko: we agree on that, don't need to convince me of anything
[18:50] mikko let's break the silos rather than create more
[18:50] pieterh however your branch becomes the silo, it's no different
[18:51] mikko but the tools give you more visibility
[18:51] mikko git log --all for example
[18:51] pieterh I have 40 gits and would rather each one just had a master branch
[18:51] pieterh than one or two having a whole bunch of branches
[18:52] pieterh but like I said, it'd be nice to have the 2.1 branch back where it belongs
[18:52] pieterh I'm not arguing against that, really
[18:52] pieterh however, it won't solve mikko's problem of "where do I send this patch"
[18:53] mikko so let's just reiterate things:
[18:53] mikko why do we send patches to mailing-list at the moment?
[18:53] mikko what is the problem that this solves?
[18:53] pieterh that's how the linux kernel process works
[18:53] sustrik 1. no patch goes publicly unnoticed
[18:53] sustrik 2. peer review
[18:54] pieterh those points are happily covered by posting a commit URI to the list
[18:54] pieterh as we saw with the HTTP transport thread
[18:54] sustrik 3. no dependency of logs on a specific commercial entity (github)
[18:54] mikko sustrik: would you argue that there would be more visibility if all commits went to mailing-list?
[18:54] mikko sustrik: at the moment your work for example is not very visible to mailing-lists
[18:55] pieterh mikko: that would be good for libzmq, not for other projects
[18:55] sustrik mikko: i would prefer to send my work there as well
[18:55] sustrik if people agree, i would start with that
[18:55] pieterh but not patches, just the commit summary, as for IRC
[18:56] pieterh mikko: this should apply to all libzmq branches which are for public consumption
[18:56] mikko github can do this: http://help.github.com/post-receive-hooks/
[18:56] sustrik actually, it up to me to decide :)
[18:56] mikko which would allow us to automate the mailing
[18:56] sustrik i'll start sending patches to the mailing list
[18:57] pieterh sustrik: I think your reluctance to post github URIs is counter-productive
[18:57] sustrik mikko: how does that work?
[18:57] sustrik creates a pull request from an email?
[18:57] mikko sustrik: github sends a HTTP post to your defined url
[18:57] mikko which can then assemble email and send to list
[18:57] pieterh sustrik: if at some point github dies, the URIs can trivially be mapped to another location, the commit IDs don't change
[18:58] sustrik mikko: that heppens when a patch is pushed to the repo?
[18:58] pieterh yes
[18:58] sustrik no good, the review should happen before the patch is pushed
[18:58] pieterh sustrik: topic branches, then
[18:59] pieterh and you can simply post the commit URI and ask for review
[18:59] sustrik how would that work?
[18:59] sustrik ah
[18:59] sustrik no log then once github fies
[18:59] sustrik dies
[18:59] mikko sustrik: what do you mean?
[18:59] pieterh see my comment just now about "when github dies"
[18:59] mikko sustrik: they are branches, everyone will have a copy
[18:59] sustrik you won't be able to trace the discussion back
[18:59] pieterh sigh
[18:59] mikko sustrik: the discussion happens on mailing-list
[19:00] mikko sustrik: only thing github does is automate the mailing
[19:00] sustrik ah you mean everybody would work on libzmq repo
[19:00] sustrik ?
[19:00] mikko sustrik: yes
[19:00] sustrik hm
[19:00] mikko think about repository and branch as different concepts
[19:00] sustrik would that require everyone to have write access to libzmq repo?
[19:00] pieterh mikko: I'm happy to switch to any new organization you propose, if you can make clear instructions for using git properly
[19:00] mikko sustrik: i think a selected crowd would be good enough
[19:01] sustrik what about others?
[19:01] sustrik mailing list?
[19:01] mikko for example
[19:01] sustrik that makes sense
[19:01] mikko what i am after is a bit smoother workflow for people who contribute more than one patch
[19:01] sustrik ack
[19:01] mikko being able to do refactoring etc in my own branch
[19:02] sustrik yes, i think that makes sense
[19:02] mikko for example in some cases there are incremental changes
[19:02] mikko or so
[19:02] pieterh mikko: what branch do your three patches go to?
[19:02] mikko pieterh: master
[19:02] pieterh do you make a topic branch with them?
[19:02] mikko pieterh: in this workflow:
[19:02] mikko i would branch off from master, do my changes
[19:03] mikko push the branch to github
[19:03] pieterh mikko: and then if they don't apply cleanly to 2.1, I ask you for help?
[19:03] mikko pieterh: yes
[19:03] mikko i think that's only fair
[19:03] pieterh perfect
[19:03] mikko let's collaborate
[19:03] mikko rather than silo ourselves
[19:03] pieterh I think this is close to the original workflow I proposed ages ago
[19:03] sustrik sounds good
[19:03] pieterh the silo is really to allow experimentation, and I think that's been very important
[19:04] sustrik but these are *topic* branches
[19:04] mikko if people who know about the patches collaborate on the different branches we can ship best possible product
[19:04] pieterh indeed
[19:04] mikko which i think is the ultimate aim
[19:04] sustrik the 2-1 is a bit different
[19:04] pieterh that was my idea of splitting 'release maintainer' from 'contributor'
[19:04] sustrik as it's a maintenance branch. not a topic branch
[19:04] pieterh sustrik: topic branches always apply to master, right?
[19:04] pieterh maintenance branches get downstreamed from master
[19:05] sustrik that's the simplest system
[19:05] pieterh makes sense to me
[19:05] sustrik however, maintainers sometimes choose to maintain a patchset without upstreaming it
[19:05] sustrik say RHEL patches
[19:05] pieterh for sure, yes
[19:05] pieterh especially when master diverges too far
[19:05] pieterh old code will have its own bugs
[19:06] pieterh we have this with 2.0
[19:06] pieterh mikko: thanks for pushing these ideas
[19:07] sustrik ok, so topic branches make sense
[19:07] pieterh I'm happy to work within any process that is documented so I can use it on Monday morning before coffee
[19:07] sustrik having stable branches in main repo as well
[19:07] pieterh yes
[19:07] sustrik however, there's still the process problem
[19:07] pieterh yes
[19:07] pieterh sustrik: you realize that mail archives can be patched
[19:07] pieterh and that any URIs to dead sites can be fixed up
[19:08] pieterh what's relevant is that commit IDs are independent of the website
[19:08] sustrik i mean the multiple processes problem, not the github problem
[19:08] pieterh I think we resolve that with clear documentation
[19:08] pieterh no ad-hoc workflows
[19:09] pieterh otherwise it'll crash and burn
[19:09] mikko testing the hooks now
[19:09] mikko brb
[19:09] sustrik i mean, if i am responsible for a repo i don't want any backward incompatible changes in minor versions
[19:09] sustrik because that can break things in production
[19:09] pieterh sustrik: I think that's a different discussion
[19:10] sustrik and i don't want to be responsible for a repo that does that
[19:10] pieterh valid, but it really requires user involvement in such decisions
[19:10] pieterh every time we've asked this question, people have answered "give us new functionality, we can handle breakage"
[19:11] pieterh I think you'll be surprised by the speed people jump onto 3.0
[19:11] sustrik most people have no experience with process
[19:11] sustrik they just want new functionality
[19:11] pieterh sure, but 0MQ is still a young product
[19:11] pieterh messaging lifecycles are 12-18 months
[19:11] sustrik they don't care about breaking other's deployments
[19:11] pieterh it's a mistake to over-estimate the depth of production deployment
[19:11] pieterh IMO
[19:11] pieterh and binding authors should be super-sensitive to this, they are the ones who will get the blame
[19:12] sustrik why i mistake/
[19:12] sustrik ?
[19:12] sustrik you can't go wrong on that side
[19:12] sustrik you can go wrong on the other side though
[19:12] mikko https://gist.github.com/1f309de5283ea59c3395
[19:12] mikko this is the email github sends if you use their pre-defined email hook
[19:12] pieterh well, look, we've solved this problem for 0MQ
[19:12] sustrik ?
[19:13] pieterh we do have rapid stable releases and freedom to break new versions
[19:13] sustrik mikko: so every change to a topic branch would go to the mailing list?
[19:13] pieterh any new functionality in the 2.x branch goes into 2.2
[19:13] pieterh as far as I'm concerned (and there have been zero actual complaints) it's solved
[19:13] mikko sustrik: every change would be mailed out
[19:13] sustrik the stable releases are not backward and forward compatible
[19:13] mikko sustrik: i can create custom hook that mails just topic branches
[19:13] pieterh sustrik: zero actual complaints
[19:13] sustrik that's why i don't want to be responsible for them
[19:14] pieterh I'm not going to stress over philosophy
[19:14] pieterh sure, that's why I'm here
[19:14] pieterh but I've no patience for another six months of "we can't improve this code because people might be using it"
[19:14] mikko brb, need to buy milk
[19:15] pieterh that is bad in a fast-moving project, sorry
[19:15] sustrik mikko: i think the point is that you don't want *all* the commits to topic branches to go to the mailing list
[19:15] sustrik just the polished version
[19:15] sustrik cyl
[19:15] pieterh sustrik: my confidence in this way of working is based on making FOSS packages for mass consumption since 1996 or so
[19:16] sustrik pieterh: ok, what about you becoming maintainer of the whole thing?
[19:16] sustrik i can work on my private repo
[19:16] pieterh sustrik: fine by me
[19:16] sustrik and you can pull whatever you want
[19:16] pieterh I think *we* as community should be maintainer
[19:17] pieterh but of processes, rather than code
[19:17] pieterh I hope you see the distinction
[19:17] pieterh we define a clear process by which code flows from contributor to user
[19:18] pieterh people end up trusting the process
[19:18] sustrik there have been one and still is one for master
[19:18] pieterh the process on master doesn't deliver code to users
[19:18] sustrik that's what i can manage
[19:18] sustrik i can still hand that responsibility to someone else
[19:18] pieterh and fwiw, you can make 3.0 compatible with 2.1 in 30 seconds...
[19:19] sustrik how so?
[19:19] pieterh how is it not compatible?
[19:19] sustrik the API and ABI have changed
[19:20] pieterh you said, "I don't want any backward incompatible changes in minor versions"
[19:20] pieterh implying I'd done that
[19:20] sustrik ah
[19:20] sustrik you dropped the devices
[19:20] pieterh they were not documented, not used, not finished, and not maintained
[19:20] sustrik well, and?
[19:21] pieterh further, several attempts to fix them were rejected on the grounds that they were scheduled for removal
[19:21] sustrik the point of stable is not to break client installations
[19:21] pieterh I'm not going to ship crap to my users, sorry
[19:21] sustrik exactly
[19:21] sustrik thus you keep them till next major version
[19:21] sustrik then drop them
[19:21] pieterh What part of "undocumented" isn't clear?
[19:22] sustrik documentation is just part of compatibility
[19:22] pieterh this is an example of dangerous prudence
[19:22] pieterh by assuming people use these in production you actually made it impossible for real device projects to happen
[19:22] sustrik well, debian package already run to that problem
[19:22] pieterh undocumented code is not deliverable in my book
[19:22] sustrik it has to do something when upgrading to 2.1.3
[19:22] pieterh sorry, I have standards
[19:23] sustrik anyway, no point in this discussion
[19:23] pieterh indeed, if you'd documented the devices they would still be there
[19:23] pieterh if you consider this "breaking the API", I'm just lolling
[19:24] sustrik that's why i don't to be responsible for the releases you make
[19:24] sustrik i am simply more prudent than you are
[19:24] sustrik that's all
[19:24] pieterh I think this is a fair balance to be honest
[19:24] sustrik evenry man has his own balance
[19:24] pieterh it certainly seems to work well
[19:24] sustrik i am pretty conservative
[19:25] pieterh I am ultraanarchist
[19:25] sustrik :)
[19:25] pieterh philosophical anarchist, to be honest, but who cares
[19:25] pieterh catch you tomorrow!
[19:25] sustrik see you
[19:42] sustrik mikko: still there?
[19:42] sustrik never mind
[19:45] yrashk btw what's the timeline for 3.0?
[19:45] yrashk if any
[19:56] sustrik yrashk: you mean, when it becomes stable?
[19:56] sustrik it depends on binding maintainers, i would say
[19:57] mikko sustrik: here now
[19:57] sustrik once most bindings are updated to work with 3.0, than it can be reasonable used
[19:57] yrashk sustrik: I just want to plan erlzmq2 update
[19:57] sustrik no haste
[19:57] yrashk like when should I start worrying about 3.0 API compatibility?
[19:57] sustrik the change is not that big actually
[19:58] sustrik mostly renaming zmq_send->zmq_sendmsg and zmq_recv->zmq_recvmsg
[19:58] sustrik and almost all socket option types were changed to int
[19:58] sustrik mikko: re topic branches
[19:59] sustrik i would say you want to develop on your repo
[19:59] sustrik and push to the topic branch once you are ready
[19:59] sustrik basically asking for review
[19:59] sustrik right?
[20:00] sustrik yrashk: i plan to add some goodies to 3.0
[20:01] sustrik to make incentives for the migration
[20:01] yrashk good
[20:01] sustrik so just wait till users start demanding 3.0
[20:01] sustrik then update erlzmq
[20:01] yrashk :)
[20:01] sustrik exactly
[20:01] sustrik subports
[20:01] yrashk what's that?
[20:02] sustrik zmq_connect ("tcp://192.168.0.111:5555.23");
[20:02] sustrik you can pass multiple flows via single port
[20:02] sustrik seb`: i was kind of hesitant about subports
[20:02] sustrik but i think i got the point
[20:03] yrashk sweet
[20:03] sustrik it's about fast deploy cycle, right?
[20:03] yrashk nice indeed
[20:03] yrashk any overhead?
[20:04] sustrik you just deploy the programs, don't have to worry about assigning ports
[20:04] sustrik yrashk: no overhead
[20:04] yrashk niiiiice
[20:04] yrashk I want it
[20:04] sustrik the downside is that you can't distinguish the feeds on networking hardware
[20:05] sustrik so you can't do say feed-based traffic shaping
[20:05] sustrik but it's a trade-off
[20:05] sustrik the user should choose
[20:05] yrashk still nice for subprotocols or somthing
[20:06] sustrik seb`: i got it at ietf plenary last week
[20:06] sustrik the theme was how downloading the client side code have shortened the deployment cycle
[20:07] sustrik tell me
[20:07] sustrik lasted 6 days
[20:07] sustrik my ass is all itching from all the sitting down
[20:08] sustrik but it's kind of interesting otoh
[20:09] sustrik so, the point made there was that fast deployment actually beats standardisation
[20:09] sustrik and i thought:
[20:09] sustrik we can think of ports assigned as a standard between the parties involved in 0mq communication
[20:10] sustrik we can deploy new code pretty fast
[20:10] sustrik but we can't break the "standard" that fast
[20:10] sustrik thus creating long deployment cycles
[20:10] sustrik which hurt the agicel business
[20:10] sustrik agile
[20:11] sustrik the consequence is, that i want suports in asap
[20:14] tproa subports sound fairly handy.
[20:17] sustrik yep, the obvious drawback is that 2 processes on the same machine cannot bind to the same port
[20:17] sustrik even though they use different subport
[20:18] sustrik this can be solved in in-kernel implementation though
[20:19] yrashk it
[20:20] yrashk it'd be interesting to try out replacing erlang's distribution with zmq-based one
[20:20] yrashk just for fun
[20:20] sustrik what's erlang distribution?
[20:20] sustrik downloading the code?
[20:21] yrashk nope
[20:22] yrashk the way it talks between nods
[20:22] yrashk http://www.erlang.org/doc/apps/erts/alt_dist.html
[20:23] yrashk the fun thing is that it is replaceable
[20:23] sustrik aha
[20:23] sustrik but it has to be a general-purpose messaging i assume
[20:24] sustrik i.e. "send to an mailbox" semantics
[20:25] yrashk afair it is much lower level
[20:29] yrashk so may be one day I'll feel adventurous enough :)
[20:29] sustrik :)
[20:30] yrashk it's good it is documented at all
[20:30] yrashk and documented fairly well
[21:10] mikko sustrik: possibly
[21:10] mikko sustrik: i want to push code as often as possible so that there is visibility to my work
[21:10] mikko and that local hardware failure doesnt cause things to get lost

Web site design and content is copyright © 2010-2011 Peter Alexander, ProDataLab. Site content licensed under the Creative Commons Attribution-Share Alike 3.0 License. ØMQ is copyright © Copyright © 2007-2011 iMatix Corporation and Contributors. Contact us for professional support. ØMQ is free software licensed under the LGPL. ØMQ, ZeroMQ, and 0MQ are trademarks of iMatix Corporation. Terms of Use ? Privacy Policy