Hi, Here's the summary of the previous IRC meeting / sprint.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 31st May 2012 Time: 15:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2012-05-31> Next meeting will be announced in advance, but will probably be on the same weekday and at the same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY Cron2, dazo, ecrist and mattock participated in this meeting. -- Discussed the original "Repair t_client.sh test after build system revolution" patch and it's alternative: <http://thread.gmane.org/gmane.network.openvpn.devel/6616> <http://thread.gmane.org/gmane.network.openvpn.devel/6616/focus=6622> Both patches had identical functionality. However, dazo ACKed the original patch, as it was not made clear why the alternative would be better and it's commit message was improper. -- Discussed the "build: check minimum polarssl version" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/6613/focus=6614> Dazo gave this patch an ACK. This one had a feature-ACK from Adriaan de Jong already. -- Discussed the "cleanup: update .gitignore" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/6596> Dazo gave this patch an ACK. -- Discussed the "build: spec: we support openssl >= 0.9.7" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/6590/focus=6589> Dazo gave this patch an ACK. -- Discussed the "build: insall README* document using build system" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/6536> Dazo gave this patch an ACK. -- Discussed the "Don't require DAF_INITIAL_AUTH to send ADDRESS/DISCONNECT messages" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/6456/focus=6457> Decided to ask James to review it. -- Decided to ask James to review the "OCC ping" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/6619> Cron2 gave this patch a feature-ACK. Decided to ask James to review it. -- Discussed the "build: detect sys/wait.h required for *bsd" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/6532> Cron2 gave this patch an ACK. -- Had brief discussion regarding relative merits of patch management using the mailing list vs. GitHub. Dazo gave an estimate of the amount of work involved when using the mailing list: - ACK: 20% - git-am: 40% - git-push 20% - mailing the ACK message: 20% So, pulling code from other repos on GitHub would probably save lots of time. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
mattock 18.00.32 meeting time dazo 18.01.21 yeah cron2 18.02.30 here I am 45 minutes to go 18.02.36 mattock 18.03.03 topic list: https://community.openvpn.net/openvpn/wiki/Topics-2012-05-31 vpnHelper 18.03.05 Title: Topics-2012-05-31 – OpenVPN Community (at community.openvpn.net) mattock 18.03.09 or rather, behind the link on that page first would be https://github.com/alonbl/openvpn/tree/build 18.03.32 vpnHelper 18.03.34 Title: alonbl/openvpn at build · GitHub (at github.com) mattock 18.03.48 oops, not a patch? dazo 18.04.12 nope, a branch, I believe mattock 18.05.05 ah yes, starts to make sense cron2 18.05.48 so where do I click to see the diff? mattock 18.06.22 https://github.com/alonbl/openvpn/commit/d7475e2323d777938c21a6b6ad97064656aa1eee vpnHelper 18.06.24 Title: build: t_client re-addition · d7475e2 · alonbl/openvpn · GitHub (at github.com) dazo 18.07.03 how do we make the commit list against the upstream master branch? that's the interesting changes L'utente jamxNL_ è ora conosciuto come jamxNL 18:07 cron2 18.07.50 that's just the very latest diff (which was also sent to the list). I'm not sure why that one is "better" than my patch, as it does the same thing except change a few texts (which I'm not liking) and adds TESTS_ENVIRONMENT (which I do not known anything about) dazo 18.08.29 As I see it, Alon's patch is more aligned towards the autotools way of doing things cron2 18.08.50 the autotools way of doing things needs changes to the way the error message is printed? dazo 18.08.52 I've compared both patches, and it does exactly the same - just being more "correct" somehow L'utente EvilJStoker è entrato nella stanza 18:09 mattock 18.09.27 dazo: do we need to look at HEAD of these branches only, or are some of the older patches missing, too? cron2 18.09.41 well, most of it is identical, except for TESTS_ENVIRONMENT, the @IPROUTE2@ test written differently (which I'm fine with) and the error message for "cannot find t_client.rc" changed in a non-helpful way dazo 18.09.54 mattock: I honestly don't know ... which is why I'm looking at the what's posted to the ML ecrist 18.10.42 *grabs popcorn before the dev war gets started* dazo 18.10.43 cron2: he actually extended the error message you proposed ... cron2 18.10.52 dazo: huh? my code has a two-line message that explains what these directories are *about* 18.11.07 echo "$0: cannot find 't_client.rc' in build dir ('${top_builddir}')" >&2 18.11.10 dazo 18.11.12 ahh! cron2 18.11.13 echo "$0: or source directory ('${srcdir}'). SKIPPING TEST." >&2 dazo 18.11.19 sorry, I mixed my windows cron2 18.11.20 and not "just list directories" and the "no openvpn binary" message is misleading, because it will never be in $top_builddir anyway 18.12.07 so, no, I cannot see why his is "better", and just dropping this without explanation *why* this is better is not going to help 18.12.40 dazo 18.13.08 agreed ... and considering his commit message is a rant instead of a commit message ....... 18.13.10 cron2 18.13.11 but let's not talk about *this* one, let's focus on the other open issues (I see a few more t_client.sh.in patches coming, as soon as mattock will start working with it and we see what needs to be improved...) 18.14.08 mattock 18.14.14 dazo: are you using GitHub as the main repository now? i.e. should I pull it 18.14.19 or clone, rather 18.14.29 dazo 18.14.37 mattock: nope, I will use sf.ent as main repo ... but I will push to github sf.net* 18.14.42 mattock 18.14.49 ok "build: check minimum polarssl version" not merged? 18.16.04 dazo 18.16.17 *really considers to NAK alons patch and ACK cron2's patch ... but considering if it's worth another flame war which will come* mattock: nope, it's on my todo list 18.16.25 that one, I'll ACK, adding Reviewed-by andj 18.16.44 mattock 18.16.48 does the polarssl patch need an ACK? ecrist 18.16.54 dazo: not NAKing a patch, simply because you're afraid of a temper tantrum is exactly the wrong thing to do cron2 18.16.57 dazo: please ACK, so we can go on with the client tests, and if the autotool-related things are really so important, we can always change that later dazo 18.17.16 ecrist: I know ... but I only have a certain amount of patience and energy .... cron2 18.17.17 *is not standing in the way of anything autotool-related as long as it's explained* dazo 18.17.28 exactly, cron2 cron2 18.19.10 mattock: is there anything else in "build" but the polarssl-version and the t_client.sh patch? dazo 18.19.13 mattock: considering, I'll dare to ack the polarssl stuff, it's just fine mattock 18.19.33 ok, two down some more to go 18.19.36 cron2 18.20.13 dazo: do you have the .gitignore one? (1cf56c407e515682e)? L'utente coderrr si è disconnesso (Ping timeout: 260 seconds) 18:20 dazo 18.20.18 cleanup: update .gitignore is fine that'll be ACKed by me 18.20.25 cron2 18.20.26 that one mattock 18.21.04 this looks fine, too: "build: spec: we support openssl >= 0.9.7 " dazo 18.21.12 yeah, that'll go in "install README* documents...." I'm double checking with the RPM managers ... I find it odd to add a workaround to a rpmbuild issue fixed almost a year ago 18.21.27 ecrist 18.22.07 what's the point? cron2 18.23.00 have these patches been on the mailing list? I don't claim to have read everything, but these look quite unknown to me dazo 18.23.06 rpmbuild has a bug related to the usage of one of its macros ... but talking about the sun .... the RPM maintainer just recommended to add this workaround, as it's present in a lot of rpm installations cron2: yeah, they have 18.23.17 cron2 18.24.02 ok dazo 18.24.08 at least I recognise what mattock points at cron2 18.24.17 then I just saved them away as "I can't comment on that" L'utente chantra_ è entrato nella stanza 18:24 dazo 18.25.23 I'm completely ignoring the syshead cleanup stuff ... that's for v2.4, I think ... we've done enough revolution for v2.3 mattock 18.25.28 so "build: insall README* document using build system" looking ok? dazo 18.27.33 mattock: seems so mattock 18.27.46 and this one is trivial, I assume: "cleanup: spec: make space/tab consistent" dazo 18.28.03 "[PATCH] Don't require DAF_INITIAL_AUTH to send ADDRESS/DISCONNECT messages" ... that's something James should look at cron2 18.28.12 where are we now? dazo 18.28.47 http://thread.gmane.org/gmane.network.openvpn.devel . vpnHelper 18.28.48 Title: Gmane Loom (at thread.gmane.org) cron2 18.29.01 dazo: that's not truly helpful mattock 18.29.03 ah, I used GitHub, dazo used mailing list archive dazo 18.29.43 cron2: if you search the subjects we mention, you'll find them really fast L'utente plaisthos si è disconnesso (Ping timeout: 272 seconds) 18:29 mattock 18.30.11 I'll let dazo take the lead cron2 18.30.13 *has no DAF_INITIAL_AUTH anywhere* mattock 18.30.43 http://article.gmane.org/gmane.network.openvpn.devel/6457/match=daf_initial_auth vpnHelper 18.30.45 Title: Gmane -- Mail To News And Back Again (at article.gmane.org) dazo 18.30.59 http://thread.gmane.org/gmane.network.openvpn.devel/6456 vpnHelper 18.31.00 Title: Gmane Loom (at thread.gmane.org) cron2 18.31.19 ah, wrong mailbox looking I was dazo 18.31.29 mattock 18.31.40 cryoda2? cron2 18.32.06 I was looking for Alon patches, not for yet something else - anyway, can't comment on that either mattock 18.32.24 let's send it to James dazo 18.32.31 mattock: can you follow that one up with James? ... and also the OCC ping patch mattock 18.32.46 yep, I'll ask him to review them cron2 18.32.46 the polarssl version got a feature-ack from andj already dazo 18.32.54 http://thread.gmane.org/gmane.network.openvpn.devel/6619 vpnHelper 18.32.55 Title: Gmane Loom (at thread.gmane.org) dazo 18.34.14 This one looks fine ... http://thread.gmane.org/gmane.network.openvpn.devel/6532 vpnHelper 18.34.15 Title: Gmane Loom (at thread.gmane.org) mattock 18.34.23 yep cron2 18.34.49 the OCC stuff looks intersting, but I'm not sure it does what it claims - it sends OCC pings and replies to them, but I can't see whether it verifies that the ping actually came back dazo 18.35.05 then there is this Android patch ... but we should probably discuss that more with Arne here when he comes back L'utente RubyPanther si è disconnesso (Ping timeout: 240 seconds) 18:35 dazo 18.35.53 cron2: agreed .... but is this a "nice to have (for some)" feature .... or "need to have (for most)" feature? mattock 18.36.35 the Android patch or the OCC patch? cron2 18.36.44 dazo: the OCC ping - I think the current implementation of "ping" is not ideal, as it needs to be synchronized between client and server. So having something that can be turned on on one side, whatever the server defaults to, is useful so "feature ACK" 18.37.02 dazo 18.37.24 cron2: okay, good! cron2 18.37.30 whether the implementation is the "right" way forward, I can't say, as I have not looked into ping and occ closely enough dazo 18.37.48 mattock: the OCC patch (Android is a must) 18.37.53 cron2 18.38.21 openssh has something similar (the ServerAliveInterval thing) next patch: sys/wait.h - autoconf religion demands that this is done, while I've expressed more pragmatic views there ("if we know we're on *BSD, we know we have <sys/wait.h>") 18.39.32 I am going to abstain on this 18.39.41 dazo 18.41.30 cron2: I think Alon discussed an issue here with krzee, where they found out this was needed cron2 18.42.06 well, OpenVPN currently builds on all FreeBSD versions, OpenBSD and NetBSD, so I'm not sure why this would be needed. But if krzee says so, then put it in. ah 18.42.41 we already broke it 18.42.51 syshead.h has 18.42.53 #ifdef HAVE_SYS_WAIT_H 18.42.56 # include <sys/wait.h> 18.42.57 #endif 18.42.57 but nobody sets HAVE_SYS_WAIT_H 18.43.04 otoh, nobody seems to *miss* it, as it still builds... 18.43.33 so maybe the inclusion of <sys/wait.h> needs to go 18.44.09 anyway: for consistency between syshead.h and configure, I hereby ACK the patch. Done. Next 18.44.45 dazo 18.44.54 The last one probably for today ... http://thread.gmane.org/gmane.network.openvpn.devel/6402 vpnHelper 18.44.55 Title: Gmane Loom (at thread.gmane.org) cron2 18.45.08 (I assume that not including <sys/wait.h> will just result in "no prototype for wait()" warnings) dazo 18.45.22 cron2: I think you're right *see a grammar mistake in the commit message ... but I can fix that * 18.46.16 cron2 18.46.22 ack on 6402 if it's dead, away with it 18.46.41 dazo 18.46.48 yeah cron2 18.47.07 ok, I have 5 more minutes mattock 18.47.25 time for 5 more patches then 18.47.26 dazo: what's next 18.47.55 cron2 18.47.58 I'll go through the syshead cleanup stuff tonight, much of it looks reasonable dazo 18.48.04 http://article.gmane.org/gmane.network.openvpn.devel/6383 vpnHelper 18.48.06 Title: Gmane -- Mail To News And Back Again (at article.gmane.org) mattock 18.48.38 I think we should include the syshead stuff if it looks clean dazo 18.48.40 cron2: yeah, but that's no hurry ... if we don't want it into 2.3 cron2 18.48.45 no idea about that dazo: 2.3 is at least two months away, so we can get some non-controversial cleanups in 18.49.07 dazo 18.49.16 agreed jamxNL 18.49.24 /win 2 oops ;] 18.49.33 mattock 18.49.40 dazo 18.49.48 I'm considering to fork the master branch soonish ... so we can start pulling in things for 2.4 into master mattock 18.49.56 good idea cron2 18.50.08 nah mattock 18.50.11 can we feature freeze 2.3 now/asap? dazo 18.50.26 mattock: that's why master is so quiet recently cron2 18.50.29 we want d12fk's windows privsep stuff and my route-gateway-ipv6 in 2.3 and master mattock 18.50.50 well, the android thingy is missing, but can we expect it to arrive soon? cron2 18.50.58 yes dazo 18.51.10 okay, so we will then have alpha2 soonish ... and then alpha3 with those last pieces d12fk 18.51.23 how about faster releases and not wait for so much so long? mattock 18.52.00 the android support could be an external patchset, too cron2 18.52.00 dazo: that sounds doable dazo 18.52.02 d12fk: I generally agree ... but it's not always easy to predict how much time (at least for my part) which is available for openvpn hacking mattock 18.52.17 d12fk: I'd prefer that approach too cron2 18.52.31 d12fk: that would be good, but I'm not sure how to get there dazo 18.52.37 when we switch to beta ... then we're doing bug fixes cron2 18.52.46 *wanted to see 2.3 end of last year* mattock 18.53.43 well, not to go off-topic, but I'd like to see a replacement for our current ACK system... it's not working as well as it should cron2 18.54.04 that's less the ACK system but some people's personalities mattock 18.54.30 well, we're constantly reviewing patches in meeting, and we have only one meeting in a week at tops... so it adds lots of delays cron2 18.54.35 we want more contributors, but that can't be achieved if every posting is greeted with "this is all so wrong, and we don't want this anyway, and it could be maintained externally" mattock 18.54.36 personalities add extra delay dazo 18.54.41 I'm willing to see more people pull in patches into a forks of the master branch ... but then we're moving towards a sub-maintainer model mattock 18.55.05 we should probably give GitHub a fair go cron2 18.55.08 dazo: I'm not sure that would actually help - if people pull in patches, they can as well ack it on the list dazo 18.55.21 cron2: fair point cron2 18.55.33 mattock: I'm not sure why that would help either. Anyone can fork sf.net anywhere, but you have seen how useful reviewing "stuff in github" is dazo 18.55.35 but lately, it's been my pulling in patches which has been partly hurting the process mattock: github doesn't simplify the code management .... it's a git repo with a fancy webUI on top 18.56.01 + social networking features 18.56.09 mattock 18.56.14 cron2: have we reviewed any stuff on GitHub? dazo 18.56.26 but in the bottom, there's the git stuff mattock 18.56.31 yeah, obviously cron2 18.56.33 dazo: how would the "dazo-bottleneck" go away if (say) I were to maintain an ipv6-sub-repo? mattock: well, we tried, with you posting links to github 18.56.43 mattock: I'm not sure what else we did 18.56.53 mattock 18.57.14 I mean the commenting features it's supposed to have L'utente RubyPanther è entrato nella stanza 18:57 cron2 18.57.47 mattock: well, not that part. mattock 18.58.01 that's what I meant with a fair go if it could help with the (initial) commenting that'd help 18.58.09 cron2 18.58.34 I'm not sure why it would speed up things if we spend our limited time trying new things all the time, instead of focusing on *code* and going *forward*... but maybe I'm just too old-fashioned 18.58.42 mattock 18.59.14 could be L'utente janjust si è disconnesso (Quit: Leaving) 18:59 dazo 18.59.24 cron2: (ipv6-sub-repo) exactly ... which is why, if more people would pull in generic patches ... I could quickly rebase your repo and push it out to all our places cron2 18.59.33 ACK-on-mailinglist works perfectly well if there is *interest* in the patches in question, and know-how. If there's no interest, I can't see why all of a sudden people would be interested in commenting in a web interface. dazo 18.59.47 cron2++ mattock 18.59.48 well, the people would have to be different people and they might be 18.59.54 cron2 19.00.01 dazo: (ipv6-sub-repo) wouldn't that be about as quick or not as "cron2 has ACKed it on the list, git-am it"? mattock: do you have a few standing in line to comment code on github? 19.00.23 mattock 19.00.52 no, but do what do we lose by trying it out? dazo 19.01.08 cron2: well, the ACK is 20% of the work, the git-am is 40%, git-push 20% and mailing the ACK message the last 20% cron2 19.01.09 mattock: time dazo: oh, so having a sub-repo maintainer would actually save so much work - then we might consider that 19.01.34 anyway, need to quit 19.01.41 "papa come eat!" 19.01.44 dazo 19.01.47 mattock 19.01.50 bye!
