IRC Log

Friday August 20, 2010

[Time] NameMessage
[00:07] rbraley I recommended ZeroMQ during my Amazon interview today
[00:16] AndrewBC How did that go?
[00:22] rbraley Slam dunk. He said of all the many applicants he'd ever interviewed my solution was by far the most scalable and ballsy! Apparently nobody had ever used Hadoop or MapReduce in a 40min interview..
[00:22] AndrewBC hehe
[00:24] rbraley I am going to make a prediction: if anyone ever does make skynet, they will use ZeroMQ to do it.
[00:24] rbraley pieterh, put that in your blog and smoke it!
[00:24] rbraley :P
[00:25] AndrewBC Heheh
[01:52] mattbillenstein hi all
[01:52] mattbillenstein seems the INSTALL doc is missing from the github repo?
[01:53] travlr what platform are you on?
[01:53] mattbillenstein linux
[01:54] mattbillenstein ubuntu
[01:54] travlr call autogen.sh to generate the ./configure file
[01:56] mattbillenstein okay, looks like I needed pkg-config, libtool, and autoconf
[02:09] mattbillenstein alright, looks like I got it installed with the python bindings -- thx!
[05:00] rbraley inspiration: http://www.archive.org/details/AlanKeyD1987
[08:55] fabian hi everybody, juste one question, I'd like to monitor zmq socket by a select. Where can I find the fd of each sockets open by zmq ??
[09:05] fabian In fact I just would like to be not blocked with a zmq read
[09:06] fabian May be there is an "alarm" or "timeout" for zmq read?
[09:10] Zao Use zmq_poll and add in a socket with which you can send anything on to break out of poll?
[09:11] Zao note that zmq_poll also supports regular FDs.
[09:11] Zao http://api.zeromq.org/zmq_poll.html
[09:11] Zao Oh, it even takes a timeout as third param :D
[09:17] fabian Ok... If I correctly understand, "items[0].socket =" must be the return value of the zmq_socket ?
[09:20] jsimmons is there any zeromq bug that causes duplicated messages followed by a busy wait lockup? in 2.0.7 perhaps? I don't think so but I thought I'd check.
[09:20] Zao It's a ZMQ "socket", whatever type that is.
[09:25] pieterh hi sustrik: you around?
[09:26] pieterh jsimmons: all known bugs are on the github issue tracker
[09:26] jsimmons I'll have a look there then thanks pieterh
[09:57] sustrik Pieter: what do you think of moving all devices to a separate project?
[09:57] pieterh what do people think of collecting device apps in one place?
[09:57] sustrik :)
[09:57] sustrik i think it's a good idea
[09:57] pieterh while writing the guide i realize there are a lot of devices to make
[09:58] sustrik but it has to be a library
[09:58] pieterh clocks, queues, loggers, etc.
[09:58] sustrik so that it can be used inproc
[09:58] pieterh yes, but initially these are all applications
[09:58] pieterh IMO over time the best ones will get librarified
[09:58] jsimmons pieterh, sustrik one of you wrote a good article about zeromq with a simple example? you were discussing a talk the other day and somebody mentioned it, I think?
[09:58] pieterh and the utterly necessary ones can go into core
[09:59] sustrik jsimmons: i am having a talk but that's kind of advanced stuff
[09:59] pieterh jsimmons: "sustrik & lucina" "sockets on steroids is the authoritative intro
[09:59] sustrik simple article... maybe the one at lwn.net
[09:59] pieterh it's mentioned on the www.zeromq.org main page
[09:59] sustrik that's the same one?
[10:00] pieterh ya
[10:00] sustrik aha
[10:00] jsimmons http://www.250bpm.com/joe ah it was this one I was thinking of
[10:00] sustrik ah, that's not really simple
[10:00] sustrik do you need a basic introduction?
[10:01] jsimmons no I understand it, I just remembered that article and wanted to read it again.
[10:01] pieterh the joe article is great but speaks to people who already know 0MQ IMO
[10:01] sustrik that's why i said it's "advanced"
[10:01] sustrik it's more about vision than technical details
[10:01] pieterh yup
[10:01] pieterh indeed
[10:01] sustrik anyway, as for the devices
[10:01] pieterh so i stared a github project, xdevices
[10:02] pieterh *started
[10:02] pieterh my idea is to collect knowledge, really, at this stage
[10:02] sustrik is there any reason *not* to allow them to be used with inproc?
[10:02] pieterh sustrik: no reason to forbid this, it's just extra work that may not be worthwhile
[10:02] pieterh it demands that they be written in C/C++ for one thing
[10:02] sustrik ah, you mean splitting the codebase into library & executable?
[10:03] pieterh i mean doing this organically...
[10:03] pieterh 1. collect knowledge and examples
[10:03] pieterh 2. collect best practice into libraries
[10:03] pieterh 3. move essential parts into 0MQ core over time
[10:03] sustrik ok, sure, as an experimental project is doesn't have to be completely versatile
[10:03] pieterh right
[10:04] pieterh also, no git process :-)
[10:04] pieterh everyone hacks master :-)
[10:04] sustrik :)
[10:04] pieterh which you can't do for libraries
[10:04] pieterh ok, so part 2 then
[10:04] pieterh i started ZFL, which can be the container for reusable devices for inproc use
[10:06] sustrik ok
[10:06] sustrik i'll have a look at it a bit later
[10:06] sustrik now, part 3
[10:06] sustrik the process!
[10:07] pieterh part 3...
[10:07] sustrik so, in linux kernel you have maintainers for parts of the code
[10:07] sustrik who should guarantee some minimal QA
[10:07] pieterh i've started learning http://nvie.com/git-model
[10:08] pieterh i think there are basic principles of ownership
[10:08] sustrik this has to do more with personal responsibility than with operational details
[10:08] pieterh we own what we make (in the sense of responsibility to users)
[10:08] sustrik right
[10:08] pieterh code that has no owner is dead or will die
[10:08] sustrik exaclty
[10:08] sustrik once we'started with this and added MAINTAINERS file to the codebase
[10:08] pieterh and any package of code has one identifiable 'main' owner
[10:08] pieterh yes, i read that
[10:09] sustrik right now it says:
[10:09] pieterh e.g. in COSS, each specification has one responsible editor
[10:09] sustrik lucina = build system + something, i don't exactly remember what
[10:09] sustrik sustrik = the rest
[10:10] sustrik if we can split the devices part, that would be nice
[10:10] pieterh sure, that's how it was for a while
[10:10] pieterh i think people are happy to take over parts they can help with
[10:10] pieterh actually that's key to scaling the contributions
[10:11] sustrik yes, this happened with language bindings
[10:11] pieterh precisely
[10:11] sustrik as for the code we are still not that far
[10:11] pieterh even if the new owners do things their own way, it's fine
[10:11] sustrik yes
[10:12] sustrik now, i can act a maintainer of the core for now
[10:12] pieterh for the code, i think it's still too integrated
[10:12] sustrik minus build system
[10:12] pieterh yes
[10:12] sustrik minus devices say
[10:12] pieterh yes
[10:12] sustrik ok
[10:12] pieterh even the three builtins can go into zfl
[10:12] pieterh no need to have these in core, in fact
[10:12] sustrik so I'll accept patches via email
[10:12] sustrik i will review them and merge them
[10:13] pieterh sounds like a nice simple process
[10:13] sustrik we have to ask mato if he's willing to do the same for build system
[10:13] sustrik mato: hullo!
[10:13] pieterh patches all go to zeromq-dev?
[10:13] sustrik where else?
[10:13] sustrik it makes them open to peer review
[10:14] pieterh i.e. not to github as issues, not to irc, not to you privately
[10:14] sustrik yes, it should be public imo
[10:14] pieterh yes, they must go to zeromq-dev
[10:14] mato sustrik: ?
[10:14] sustrik we are discussing process and QA
[10:14] pieterh with a standard subject that can be search/filtered easily
[10:15] sustrik i've just said i can take care of merging the patches to the core
[10:15] pieterh we can extend this to other Z* projects too
[10:15] sustrik but i cannot do the same with build system
[10:15] pieterh bindings, docs, zfl, zdevices, etc.
[10:15] mato guys, can we please discuss process and QA in person in Bratislava next week?
[10:15] sustrik [PATCH]
[10:15] pieterh mato: :-) we're thinking out loud
[10:15] pieterh [PATCH] is good
[10:16] mato pieterh: yes, fine, but i have a release to make for a client
[10:16] sustrik ok, no haste
[10:16] pieterh mato: yes, i know, no haste
[10:16] mato pieterh: and i would like to be part of the discussion
[10:16] sustrik there are not much build system patches anyway
[10:16] pieterh sustrik: i'm also using http://nvie.com/git-model
[10:17] pieterh but it may be that by keeping individual projects small, we don't need this
[10:17] sustrik dunno, i would like to use something that's 100% proven
[10:18] pieterh what does "100% proven" mean?
[10:18] pieterh how can you determine if something is 95.6% proven?
[10:18] sustrik already used in a large scale project for a reasonable amount of time
[10:18] pieterh this one is
[10:18] sustrik what's the project?
[10:18] pieterh read the page, if you have time
[10:18] sustrik ok
[10:19] pieterh however it's rather complex and IMO provides interesting pieces to reuse, rather than a fixed template
[10:19] pieterh but... it looks like very robust workflow
[10:20] guido_g and easy to understand
[10:20] guido_g ømq is going to change my life... just ordered 2 books about git
[10:21] sustrik :)
[10:21] pieterh :-)
[10:21] pieterh what git really really really needs is this kind of graphic workflow layer
[10:22] sustrik http://github.com/zeromq/zeromq2/network
[10:23] jsimmons the branches view is nice too
[10:23] jsimmons http://github.com/zeromq/zeromq2/branches
[10:24] pieterh sustrik: I mean, explaining how to branch and merge precisely
[10:24] sustrik jsimmons: nice
[10:24] sustrik ah, ok, true
[10:24] sustrik how can i get a branch to my box?
[10:24] jsimmons there's tortoise git, but I don't know how good that is
[10:25] sustrik been trying to do it yesterday, but no success
[10:25] pieterh git checkout -b unstable --track origin/unstable
[10:25] jsimmons there's a shortcut for that too...
[10:25] pieterh where 'unstable' is the branch name
[10:25] pieterh but if you clone the whole repository you get all branches
[10:25] sustrik no, i don't
[10:26] pieterh let me test that...
[10:26] sustrik clone zeromq2 -> i got master
[10:26] jsimmons yeah you get all the branches when you clone
[10:26] sustrik and that's it
[10:26] sustrik lemme show
[10:26] jsimmons but you have to explicitly check them out into the work directory
[10:27] pieterh ph@ws200901:~/tmp$ git clone git@github.com:zeromq/zeromq2.git
[10:27] pieterh ...
[10:27] pieterh Resolving deltas: 100% (4228/4228), done.
[10:27] pieterh ph@ws200901:~/tmp$ cd zeromq2/
[10:27] pieterh ph@ws200901:~/tmp/zeromq2$ git branch
[10:27] pieterh * master
[10:27] pieterh ph@ws200901:~/tmp/zeromq2$ git checkout wip-shutdown
[10:27] pieterh Branch wip-shutdown set up to track remote branch wip-shutdown from origin.
[10:27] pieterh Switched to a new branch 'wip-shutdown'
[10:27] pieterh ph@ws200901:~/tmp/zeromq2$
[10:29] sustrik here's what i get:
[10:29] sustrik sustrik@istvan:~$ git clone git@github.com:zeromq/zeromq2.git zeromq2-test
[10:29] sustrik Initialized empty Git repository in /home/sustrik/zeromq2-test/.git/
[10:29] sustrik ...
[10:29] sustrik Resolving deltas: 100% (4228/4228), done.
[10:29] sustrik sustrik@istvan:~/zeromq2-test$ git checkout wip-shutdown
[10:29] sustrik error: pathspec 'wip-shutdown' did not match any file(s) known to git.
[10:29] sustrik sustrik@istvan:~/zeromq2-test$
[10:32] jsimmons old git version maybe sustrik?
[10:32] mato sustrik: your git is weird, try git checkout origin/wip-shutdown
[10:32] pieterh sustrik: git --version?
[10:33] pieterh git checkout -b wip-shutdown --track origin/wip-shutdown
[10:34] sustrik yes, that works
[10:34] pieterh git has gotten smarter
[10:34] pieterh you used to have to tell it explicitly
[10:35] sustrik i still do for some reason
[10:35] pieterh git --version
[10:35] pieterh what does it say?
[10:35] sustrik 1.6.3.3
[10:35] pieterh so, upgrade to git 1.7
[10:35] sustrik ok, let me try
[10:36] mato sustrik: only upgrade if you have a way of upgrading via your distro
[10:36] sustrik i don't
[10:36] pieterh what's your distro?
[10:36] sustrik but maybe i should upgrade the distro
[10:36] sustrik k.koala
[10:36] pieterh yeah
[10:37] pieterh latest ubuntu has great git integration: command completion etc.
[10:37] pieterh git checkout w[tab]
[10:38] sustrik !
[10:39] pieterh ?
[11:13] pieterh has anyone experienced weirdness with pipeline sockets?
[11:13] pieterh i have a really simple 3-stage pipeline that just won't work
[11:13] pieterh http://gist.github.com/540065
[11:35] pieterh also affects pub/sub sockets
[11:35] pieterh fuller description at http://github.com/zeromq/zeromq2/issues/#issue/49
[15:46] pieterh sustrik: I have made a bug report for that assertion failure: http://github.com/zeromq/zeromq2/issues/#issue/49
[15:46] sustrik pieterh: yes, seen it
[15:47] sustrik or what's the name
[15:47] sustrik it took like 3hrs
[15:47] pieterh slow downloads?
[15:47] pieterh did you do an upgrade or a real re-install?
[15:47] sustrik yes, something seems to be not ok with my isp
[15:48] sustrik upgrade
[15:48] pieterh painful
[15:48] pieterh but welcome to the future
[15:48] pieterh or at least the very recent past
[15:48] sustrik :)
[15:51] sustrik is there any way to get my toolbar buttons to the right?
[15:51] sustrik titlebar
[15:51] pieterh ubuntu or kubuntu?
[15:52] sustrik ubuntu
[15:52] pieterh there is probably a setting in the gnome configuration thingy
[15:52] pieterh nothing in the UI I can see
[15:54] pieterh sustrik: should i continue to hack on that test case, perhaps break into three processes and see if it still fails?
[15:55] sustrik the backtrace would be helpful
[15:55] pieterh ok, added to the issue
[15:55] pieterh can't you reproduce it?
[15:56] sustrik i'm doing five things in parallel
[15:56] pieterh ok, np
[15:56] sustrik haven't yet tried
[15:56] pieterh then put this aside for now
[15:56] pieterh i'm sure it will reproduce immediately
[15:57] pieterh it's in 2.0.7 so can't be urgent
[15:57] pieterh IMO it's related to multiple threads on same context
[15:57] sustrik let me see the backtrace
[15:57] pieterh http://github.com/zeromq/zeromq2/issues/#issue/49
[15:58] sustrik hm, values optimised out
[15:58] sustrik never midn
[15:59] sustrik i'll test it later on
[15:59] sustrik aha
[15:59] sustrik i know what's the problem
[16:00] sustrik pull/push require only a one-way pipe
[16:00] sustrik hm...
[16:00] sustrik combined with inproc
[16:01] sustrik i have to check
[16:01] sustrik anyway, it's inproc thing almost for sure
[16:01] pieterh i get the same error with pub/sub
[16:01] sustrik yes
[16:01] pieterh and similar strange behaviour with tcp: or ipc:
[16:01] sustrik if you swich to ipc or tcp it will go away
[16:01] pieterh except no assert, just nothing arrives on recv()
[16:01] sustrik ah
[16:01] pieterh see the bug report, i have 4 test programs, all do weird wrong stuff
[16:02] pieterh it's like the connection is not being made, at all
[16:02] sustrik ok, i'll have to inspect in depth
[16:02] pieterh could you just take a look at one program, see if i'm doing anything obviously wrong?
[16:02] pieterh they are really simple
[16:03] pieterh http://gist.github.com/540112 for example
[16:09] sustrik pieterh: subscription is missing in step2
[16:10] pieterh you're right!
[16:10] pieterh ok, let me retest with that...
[16:11] pieterh ok, i get the 'right' bad behaviour
[16:11] pieterh as with other socket types
[16:11] pieterh step1 to 2 works, step 2 to 3 always fails
[16:11] sustrik the assert?
[16:11] pieterh if i use inproc i get an assert
[16:12] pieterh if i use ipc or tcp the second recv hangs forever
[16:12] pieterh pub/sub or push/pull give same results
[16:12] pieterh first socket pair work, second socket pair fail
[16:13] sustrik ok, i'll have a look
[16:14] pieterh i'm testing with three separate processes now
[16:21] pieterh i'm doing something really stupid with these test programs but don't know what :-(
[16:21] pieterh can't even make it work as separate processes...
[16:27] pieterh sustrik: ok, i found my utterly stupid mistake
[16:27] pieterh i'm going to rollback now and fix up all the testcases
[16:27] sustrik ?
[16:28] sustrik the assert is definitely a bug
[16:28] pieterh sigh... connecting wrong socket, input instead of output
[16:28] sustrik ok, so i'll fix the inproc stuff
[16:28] sustrik and that should do
[16:28] pieterh the assert is a bug but providing you broken testcases isn't useful
[16:28] pieterh let me clean up the issue and provide a clean testcase
[16:31] sustrik thx
[16:53] pieterh ok, just to confirm that I can provoke the assert but it requires a buggy application
[16:53] pieterh when i fixed my test cases they all worked perfectly
[16:53] mato pieterh: yo
[16:54] pieterh i've made minimal programs to provoke the assert, which hits SUB and PULL
[16:54] pieterh http://github.com/zeromq/zeromq2/issues/#issue/50
[16:54] mato pieterh: how's the baby & mother?
[16:54] pieterh hi mato
[16:54] pieterh mato: back home already, sylvie is made of tough stuff
[16:54] pieterh baby is doing great
[16:54] pieterh learning git workflows
[16:54] travlr pieterh, a big congrats to you all
[16:55] mato pieterh: height/weight/name/sex? inquiring minds want to know...
[16:55] pieterh 3.3kg, Gregor Frans Mfumu Hintjens, male
[16:55] pieterh i posted on facebook and saved a few trees
[16:56] mato neat
[16:56] mato pieterh: are you coming here next week?
[16:56] pieterh travlr: thanks :-)
[16:56] pieterh mato: yeah, Monday
[16:57] pieterh sustrik: so to provoke the assert, one connects a sub to a sub, or a pull to pull, and reads from either
[16:58] pieterh it is kind of a DoS because it lets you crash arbitrary sockets by connecting to them wrongly
[16:58] sustrik yes, there's some problems with creating pipes between two sockets
[16:58] pieterh but it only affects inproc afaics
[16:58] pieterh so it's really not a big issue
[16:58] sustrik yes
[16:58] mato sustrik: is there a way we can make sure that you can't connect socket X to Y if that is just silly?
[16:58] mato sustrik: systematically?
[16:58] pieterh mato: yes, we will need to do this
[16:58] sustrik shouldn't be hard to fix either
[16:58] pieterh it has to go into the protocol IMO
[16:59] pieterh otherwise people will start to connect PUB to PULL, kind of stuff
[16:59] sustrik silly = uncompatible patterns, roght?
[16:59] pieterh yes
[16:59] mato sustrik: yes
[16:59] sustrik yes, it should be done
[16:59] pieterh yes, it's in the 3.0 page I think
[16:59] mato sustrik: for all except pub/sub it should be fairly easy to add this to the initial message sent on connection establishment, no?
[16:59] pieterh "Pattern checking" on http://www.zeromq.org/docs:3_0
[17:00] sustrik rather for anything aside PGM
[17:00] mato ah, right
[17:00] pieterh mato: don't you read the website ? :-)
[17:00] mato yes
[17:00] mato pieterh: no
[17:00] pieterh :-)
[17:00] pieterh it's nice that people reinvent the same solutions because it kind of proves that that's the right direction to go
[17:02] mato and i still have 260 unread messages in the list inbox, need to go through those :(
[17:02] pieterh mato: i was _going_ to send out SMSs but my lovely android phone collects every single %!$# contact it can find
[17:02] pieterh so my contact list is 5,000 entries long
[17:02] mato pieterh: ah :-) that would be true SMS SPAM then
[17:03] mato expensive, too
[17:03] pieterh i gave up selecting people to SMS to after the Bs
[17:03] mato doesn't it split the contacts into "contacts you're actually interested in" and "everything else" ?
[17:04] pieterh that'd be nice, wouldn't it...
[17:04] mato yes :-)
[17:04] pieterh mato: so we were discussing breaking stuff out of the zmq core project
[17:05] mato pieterh: breaking yet more stuff out? it's pretty minimalist as is
[17:05] pieterh i think the general idea is to create smaller projects, each with one or two maintainers, each focused on one thing
[17:05] pieterh it would allow simple workflow on each project
[17:05] mato yes, but what did you have in mind?
[17:05] mato to break out ...
[17:06] pieterh i like sustrik's "send me patches by email, i'll review and apply them"
[17:06] pieterh so...
[17:06] pieterh starting with stuff that does not really fit into core and which is a maintenance job
[17:06] pieterh devices (mains())
[17:06] pieterh then devices (methods)
[17:07] mato anything else?
[17:07] pieterh we already have independent projects for bindings
[17:07] pieterh and for the user guide
[17:07] mato yes, but the bindings are fairly naturally small worlds of their own
[17:07] pieterh yes
[17:07] mato devices, i'm not so sure
[17:07] mato given that the devices are actually both part of the overall power of 0mq
[17:07] pieterh so devices... this will require time to settle down
[17:08] pieterh but what i think, have seen so far...
[17:08] pieterh is that we will end up making a lot of devices
[17:08] pieterh timers, reactors, queues, etc.
[17:08] pieterh in random languages
[17:08] sustrik i would say devices are naturally separated from the core
[17:08] pieterh that's the first thing, we have already seen this start
[17:08] sustrik think of a HW device
[17:08] pieterh yes
[17:08] pieterh naturally separate
[17:09] pieterh made by different people, to solve different problems
[17:09] mato sustrik: well, if you think so. i just had the feeling that given that the concept of devices is so important in the long term vision
[17:09] pieterh the only reason the queue device is built-in today is that the protocol ain't properly documented AFAICS
[17:09] pieterh devices are REALLY important, no doubt about it
[17:09] mato sustrik: that it would be good to at least keep a core set of devices in the distribution
[17:09] pieterh mato: coming to that, hang on...
[17:10] pieterh not proposing to scrap that
[17:10] pieterh proposal is (and feel free to beat this up):
[17:10] pieterh - collect device applications (random code like zmq_deviced, etc.) in a separate repository
[17:11] pieterh - encourage experimentation in all languages
[17:11] pieterh this is the device 'wiki'... no workflow, no releases
[17:11] pieterh step 2:
[17:11] pieterh take best practice from that and package for reuse
[17:11] pieterh - in zfl, perhaps, or similar library depending on language
[17:11] pieterh step 3:
[17:12] pieterh take best of that and package into zmq core
[17:12] pieterh - like queue, forwarder, and streamer
[17:12] pieterh so the more mature the device the wider the distribution it gets
[17:12] mato pieterh: that sounds fine
[17:12] mato pieterh: with one caveat
[17:13] pieterh shoot
[17:13] mato pieterh: that at step 3, anything going into core follows core's rules; in other words basically C (ideally C++) with no external dependencies
[17:13] mato pieterh: at least for now
[17:13] pieterh yes, precisely
[17:13] travlr +1... from one in the lowest depth of the peanut gallery :)
[17:14] pieterh that's exactly it
[17:14] pieterh so by doing this, we remove xmlStore or whatever from the distro
[17:14] mato ?
[17:14] pieterh don't need it any more
[17:14] pieterh no external dependencies
[17:14] mato you're proposing removing the current devices? i didn't catch that
[17:15] sustrik libuuid :(
[17:15] mato sustrik: i mean no big huge tool-du-jour dependencies
[17:15] sustrik i would say the devices should be in a separate package
[17:15] mato sustrik: unless we all agree
[17:15] pieterh mato: yes, moving main programs to separate git
[17:15] sustrik the rationale:
[17:15] pieterh i've already made that, see http://github.com/imatix/zdevices
[17:15] sustrik zmq-core can be fully stabilised
[17:15] pieterh yes
[17:15] sustrik while devices are still in move
[17:16] pieterh experimentation is vital but not on the same git
[17:16] pieterh different licenses (GPL, not LGPL)
[17:16] mato well, some experimentation will always happen in the "same git" since there is no such thing as the "same git" anyway
[17:16] mato but yes, good plan otherwise
[17:16] mato i suggest that this is announced on the mailing list
[17:16] pieterh ok... good... and this really reduces the need for formal workflows
[17:17] pieterh it can become: "email patch to maintainer". period.
[17:17] pieterh that is zeroworkflow
[17:17] pieterh mato: i'd actually suggest a separate email list, zeromq-patch@etc... if we do that
[17:17] mato pieterh: maybe, not yet, to be discussed
[17:17] pieterh ack
[17:17] mato next week
[17:18] sustrik then you are missing 350 people who could possibly review the patch
[17:18] mato yes, not right now
[17:18] pieterh true
[17:18] pieterh i really like the lazy workflow though
[17:18] pieterh it seems perfect
[17:19] sustrik that's linux kernel way of doing it, no?
[17:19] sustrik send the patch to lkml
[17:20] mato sustrik: mostly, yes
[17:20] mato sustrik: but you still need a workflow for the people actually committing
[17:20] mato sustrik: those patches
[17:20] sustrik no doubt
[17:20] mato sustrik: which is what we need to discuss next week
[17:20] mato sustrik: i will present how i think it works
[17:20] mato sustrik: ok?
[17:20] mato sustrik: next week, in person, at a table
[17:20] sustrik ok, np
[17:21] mato pieterh: for experimental repos, bindings, etc, anyhow, the workflow is mostly determined by the maintainer
[17:21] sustrik i like that it makes things simple for contributors
[17:21] mato yes, of course
[17:21] sustrik while burdening only committers with the process
[17:21] mato yes
[17:24] pieterh ok, i've renamed 0MQGuide repo to zguide
[17:25] pieterh zo, we 'af zguide, zdevices, unt zfunctionlibrary oder zfl
[17:25] pieterh i am going to zbeach with the family, cyal
[17:25] mato :)
[17:25] mato cya
[17:26] sustrik cya
[17:26] pieterh cya mato :-) cya sustrik

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