Hi, Here's the summary of the previous community meeting.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday, 7th July 2011 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-07-07> Next meeting will be announced in advance, but will 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/world clock> or with $ date -u SUMMARY andj, dazo, ecrist, jamesyonan and mattock were present in this meeting. -- Discussed issues of building OpenVPN from the "tmp/winbuildfix" branch in openvpn-testing.git. Noticed that there was a simple typo that triggered the only remaining error in win32.h. Mattock will fix this and provide a patch. -- Discussed the "IPV6_RECVPKTINFO vs. IPV6_PKTINFO" patch: <http://sourceforge.net/mailarchive/message.php?msg_id=27714628> Decided to take this up with jjo and cron2, as they're responsible for the IPv6 code in OpenVPN. -- Discussed "Bug: extended x509-username-field broken in git" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/4801> Andj had provided a fix to the same issue earlier than Markus, so it was decided to implement andj's version. -- Discussed andj's doxygen patchset: <http://thread.gmane.org/gmane.network.openvpn.devel/4740> Jamesyonan gave this patchset his ACK, provided that it does not change any functionality. Dazo will verify that and then merge the patches to Git. -- Discussed the possibility of arranging "sprints" where large patchsets (such as andj's) would be reviewed, fixed and ACKed in one go. The patches would still be first published on the mailinglist and would not be merged into Git until a summary of each sprint session was sent to the mailinglist for review. This would allow input even from those who were unable to attend the actual sprint. Smaller patchsets and single patches would still be handled through the mailinglist. If they stayed there for too long (1-2 weeks) without any comments, they could be handled in a sprint, too. Also, whenever possible, a poll (e.g. Doodle) would be arranged prior to sprint, so that as many developers as possible could attend. The Gerrit tool was mentioned, too, as a tool we could potentially use to ease the patch review process: <http://code.google.com/p/gerrit> -- Decided to arrange the next meeting next Thursday, but 1 hour earlier that usual (17:00 UTC). The meeting would also include a sprint. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
hi guys dazo 11:01:44 mattock: just arrived mattock 11:01:45 hi dazo 11:01:51 hey all andj 11:02:31 evening mattock 11:02:38 topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2011-07-07 dazo 11:02:39 grendal-prime: I don't think we're closer to a solution yet ... unfortunately ... vpnHelper 11:02:39 Title: Topics-2011-07-07 â OpenVPN Community (at community.openvpn.net) dazo gets ready for meeting 11:03 mattock 11:03:55 what if we start from the top? 11:03:57 dazo 11:04:01 agreed mattock 11:04:40 ok I think the first topic is mostly for dazo... 11:04:49 any clues what is still missing? 11:04:56 dazo 11:04:56 I vaguely remember these inet_*to*() issues ... and we removed some stuff (#ifdef) as these functions were present in MSVC mattock 11:05:00 yeah, me two me too 11:05:06 dazo 11:05:18 I think it was cron2_ who figured out this last time mattock 11:06:00 I think so too... it's just that I cross-checked my private Git tree (which builds) and winbuildfix branch... and saw no differences dazo 11:06:09 wait a minute .... redefinition; different type modifiers ... that indicates that there are some conflicting function declarations this is related to the mingw compatibility layer ... as mingw, iirc, doesn't have these inet_?to?() functions 11:06:50 mattock 11:07:15 would it help if put my private git tree somewhere for download? dazo 11:07:39 yeah, that could help a little bit ... just to make sure we compare apples and apples mattock 11:07:48 or, actually, I could take a diff from the offending files didn't have time to do that 11:07:54 just a sec 11:08:01 dazo: how much time do you have? 11:08:07 one hour? 11:08:11 dazo 11:08:25 today I have a little bit more andj: which platforms do you test your stuff on? 11:09:09 andj 11:09:26 At the moment just Ubuntu/RedHat dazo 11:09:35 okay btw, which versions? 11:10:04 andj 11:10:04 I haven't got a windows development machine set up at the moment Ubuntu 10.04 and 11.04 (both 64-bit), and RHEL 6 64-bit 11:10:30 dazo 11:10:42 goodie andj 11:10:58 At some point in the future, I'll have a nice little build farm, but not atm dazo 11:11:04 well, feel free to grab mattock ... he's our build farm farmer 11:11:32 ecrist 11:11:40 if someone donates a license, I can get a copy running on ike asap... andj 11:11:44 I'm quite partial to jenkins though 11:11:50 dazo 11:12:34 oh, true! mattock: we can have a look at the winbuild stuff later today, perhaps? 11:12:59 mattock 11:13:05 http://pastebin.com/QnxyTv8r ^^^ interesting 11:13:34 not really any difference per se 11:13:48 andj 11:14:00 V vs. C? dazo 11:14:05 well, that difference might explain this issue mattock 11:14:16 andj: good catch! that's it 11:14:18 dazo 11:14:21 as I believe _MSC_VER is the proper one mattock 11:14:30 yeah, it is andj 11:14:31 took me three reads to see it 11:14:33 dazo too 11:14 mattock 11:14:40 that's settled, then next topic 11:14:42 dazo 11:15:12 IPV6_RECVPKTINFO vs. IPV6_PKTINFO ... that's probably cron2_ or JJO stuff mattock 11:15:35 might be postpone to next meeting? 11:16:07 dazo 11:16:17 Need to spend some time digging into the differences between those two defines, on *BSD, OSX, Windows and Linux ... to see if we should switch or do something OSX specific yeah, or discuss as soon as cron2_ shows up again ... he might know more about it 11:16:39 mattock 11:16:59 ok, let's do that http://thread.gmane.org/gmane.network.openvpn.devel/4801 11:17:42 vpnHelper 11:17:45 Title: Gmane Loom (at thread.gmane.org) andj 11:18:04 I just sent out a follow-up I accidentaly fixed that 11:18:12 dazo 11:18:18 this one? andj 11:18:22 in the SSL patches dazo 11:18:29 heh ... nice! mattock 11:18:32 "I accidentally fixed that" lol good, that's settled 11:18:41 andj 11:18:47 Well I noticed it, though, that's weird But it might be a good candidate for 2.2 11:18:55 dazo 11:19:03 andj: want to elaborate what the fix is? and can it be easily cherry-picked to 2.2? 11:19:14 andj 11:19:50 Cherry-pick no, but the patch that Markus sent is good I think https://github.com/andj/openvpn-ssl-refactoring/blob/master/ssl_verify.c#L586 11:19:58 vpnHelper 11:19:59 Title: ssl_verify.c at master from andj/openvpn-ssl-refactoring - GitHub (at github.com) andj 11:20:22 There I call a single function that handles both extended and normal CNs (for OpenSSL, PolarSSL backend doesn't support that kind of enumeration at the moment) 11:20:40 dazo 11:21:00 I'm sceptic to the x509_username_field+4, ... as I'm not sure it will always be prefixed with 'ext:' ... andj 11:21:01 usernames that is of course, not CNs That's just a convention that openvpn added, isn't it? 11:21:22 dazo 11:22:27 yeah, another patch (from Markus I believe) extends the x509 username feature to take an argument, which can make use of extended attributes as well andj 11:22:27 Thing is, that code's already there, Markus' patch just fixes the fact that OpenVPN then mishandles the case where you're at error depth != 0 dazo 11:22:33 prefixed, with 'ext: ' 11:22:34 andj 11:22:50 ah, that's not in 2.2? andj blushes 11:22 dazo 11:23:08 I need to check the changelog, don't recall andj 11:23:51 you're right then it's problem solved 11:23:58 http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn.git;a=blob;f=ssl.c;h=6d9a9fd376dd8397085e96454dfdae5b622066db;hb=68deffc892173e1d003e4da1ad6811e8ba28a51e#l810 11:24:11 vpnHelper 11:24:12 Title: SourceForge - openvpn/openvpn.git/blob - ssl.c (at openvpn.git.sourceforge.net) andj 11:24:40 is the 2.2 part where that happens, and that doesn't include the ext: stuff I somehow just thought it was also in 2.2, sorry 11:24:59 dazo 11:25:51 commit 3fa86d237721ca113fa020b7e888a1e10374a560, which adds this extra stuff is only in master as far as I can tell now 11:25:59 andj 11:26:11 In my patches the code now lives here https://github.com/andj/openvpn-ssl-refactoring/blob/master/ssl_verify_openssl.c#L192 vpnHelper 11:26:13 Title: ssl_verify_openssl.c at master from andj/openvpn-ssl-refactoring - GitHub (at github.com) dazo 11:26:46 ahh, yeah, that looks like this part mattock 11:29:06 still somebody here? andj 11:29:18 hi mattock 11:29:23 hi! (deja vu) 11:29:27 dazo 11:29:31 where am I and why am I here? 11:29:34 mattock 11:29:44 anyways, did we cover Markus' patch? add to "master" and skip 2.2? 11:29:54 andj 11:30:09 As long as you accept mine, then you don't need Markus' patch dazo 11:30:17 yeah, this is not 2.2 stuff at all, afaics ... this feature isn't available in 2.2 andj 11:30:25 indeed sorry for the confusion 11:30:32 dazo 11:30:48 and we're skipping Markus' patch as andj fixed it "first" mattock 11:31:07 ok, somebody should mention this to Markus, then shall I? 11:31:17 andj 11:31:34 sure dazo 11:31:43 andj: could you? and just point him to the patch which fixes it andj 11:32:00 ok, will do mattock 11:32:03 nice! on to "status of andj's patches"? 11:32:22 dazo 11:33:03 I've started at least, haven't had time to complete doxygen stuff yet ... but it's a lot of good stuff so far jamesyonan: have you had time to review some of them? 11:33:18 jamesyonan 11:34:26 I'm fine with the doxygen stuff as long as it doesn't change any functionality. andj 11:34:31 I've worked on the plugin stuff, fixing the earlier USE_SSL bug (or the lack thereof) dazo 11:35:36 jamesyonan: so you've been through the documentation and it is accurate or precise enough? jamesyonan 11:36:12 yes, the quality of the documentation looks very good mattock 11:36:27 good, perhaps it can be merged to "master", then? dazo? 11:36:31 dazo 11:36:41 okay, then I'll do the review where I focus on verifying that it doesn't change functionality this will go quicker 11:36:45 mattock: when I've verified the last stuff ... yes, I'll merge it into master 11:37:11 mattock 11:37:14 nice! andj 11:37:21 nice! 11:37:23 mattock 11:37:23 paves way for the next patches dazo 11:37:29 I'm feeling sorry for not having the needed (time) bandwidth to manage this faster ... or that more people would join in on such reviewing ... but doing our bests here 11:38:16 andj 11:38:55 As long as it gets done in time for alphas I'm happy, just hope more people look at the code patches they're easier to follow for us coders anyway 11:39:05 dazo 11:39:41 to be very honest ... I think the silence just indicates a) nobody have looked at it .... or b) nothing highly critical stands out mattock 11:39:57 sounds about right dazo 11:40:13 there are those who responds surprisingly quickly on crappy stuff mattock 11:40:26 dazo: I was just about to say the same andj 11:40:33 I can understand that though mattock 11:40:35 so I think people are looking at the patches, at least quickly dazo 11:40:41 yeah mattock 11:41:22 dazo: you did some reviewing of the remaining andj's patches, too? I was wondering if (given the high number of patches) tracking their ACK/NACK status on the Wiki would make sense... 11:41:58 dazo 11:41:59 I've not had time for it yet, unfortunately ... well, the plug-in patches sent today or yesterday(?) looks good mattock: maybe, yeah 11:42:11 mattock 11:42:24 I can setup such a Wiki page, if you'd like andj 11:42:27 If the mailing list approach doesn't work, could we try to go for a sprint-like session at some point? Have a look at them together, and ack/nack/immediately fix problems dazo 11:42:30 perfect! mattock 11:42:39 andj: sounds very good dazo 11:42:42 andj: that makes sense andj 11:42:51 would be more interactive, and probably quicker? mattock 11:42:56 yeah, agreed especially if the issues are relatively minor 11:43:07 andj 11:43:30 mattock: that's what I'm expecting/hoping and if anything major comes up, we can put it aside, and continue on to the next patch regardless 11:43:50 dazo 11:43:54 from my count .... I think andj have provided about 100 commits .... so 100 minor changes is kind of challenging itself andj 11:43:55 and ack that issue later dazo 11:44:01 agreed mattock 11:44:03 I'm thinking that we could try using Doodle or something to arrange such sprints to get maximum amount of developers involved 11:44:19 andj 11:44:22 sounds good, could you set that up? mattock 11:44:28 andj: I sure can -> TODO 11:44:32 -> TODO 11:44:51 oops 11:44:53 dazo 11:45:36 btw .... jamesyonan: how is your git migration going? jamesyonan 11:46:30 I've got the server provisioned for it, and I'm planning on starting the migration in the next week or so. dazo 11:46:47 nice! mattock 11:47:34 jamesyonan: what do you think about having sprints where we work on larger patchsets (such as those of andj), fixing and ACKing large number of patches at once? the mailing list approach does not scale too well if there are tons of patches 11:47:50 andj 11:48:41 It might be a good model for future refactorings towards 3.0 as well dazo 11:48:56 yeah andj 11:49:17 Another option is something code review like, similar to gerrit (http://code.google.com/p/gerrit/) vpnHelper 11:49:18 Title: gerrit - Gerrit Code Review - Google Project Hosting (at code.google.com) mattock 11:49:34 we actually had some good discussions about OpenVPN 3.0 yesterday, so that's definitely moving forward sooner or later jamesyonan 11:49:37 do you mean combining patches and testing them as a group? mattock 11:49:59 more like group review + development seeing what issues the patches have an fixing them right away 11:50:20 pretty similar to what we have now, but fixing would be "integrated" into the meeting 11:51:08 andj: correct? 11:51:14 jamesyonan 11:51:30 so we would be building stuff and testing during the meeting? andj 11:51:46 mattock: yeah, that's what I was think mattock 11:51:59 jamesyonan: if necessary, yes andj 11:52:19 mostly reviewing existing patches, and bouncing feedback around rapidly instead of having a long mailinglist discussion about every patch in turn 11:52:33 dazo 11:54:32 I'm in favour of this approach ... I know when we discussed earlier, someone on the ML said that it would exclude those not participating in the meetings (mostly due to time zone issues) ... but we've gone now about 1 year with this approach, and it's too slow mattock 11:55:03 I think we should try sprints for larger and more difficult patches/patchsets jamesyonan 11:55:26 I would tend to agree dazo 11:55:28 yeah, definitely bigger patches ... like 5-10 patches and more mattock 11:56:01 I think individual and relatively simple patches can be handled adequately on the ml and we should definitely send a link to the patches to openvpn-devel, before the sprint 11:56:19 and a summary after the sprint, before merging them to Git 11:56:31 that way, anybody _can_ participate, if they want 11:56:40 dazo 11:56:50 to some degree small patches works, but I'd say if it stays on the list for a week or two without comments, sprinting it isn't bad mattock 11:57:11 yeah, and that's actually pretty similar to what we've done so far with these meeting patch queues except that we have not fixed stuff at the same time 11:57:21 dazo 11:57:25 yeah, exactly ... mostly due to impatience andj 11:58:01 Even just having a list of issues with a whole patchset would would be a good start mattock 11:59:11 when should we try to arrange the first sprint? next week? 11:59:13 andj 12:00:15 I thought the doodle was a good idea, I have time next week Just not sure when, as my work calendar is.. at work 12:00:31 dazo 12:00:47 I believe next week can work out for me jamesyonan 12:01:24 same time as meeting? mattock 12:02:23 we could try that at first, but in the future we should probably setup polls (e.g. doodle) before each sprint dazo 12:02:23 jamesyonan: does that fit your schedule well? andj 12:02:26 If it's possible, I'd like to do it somewhere during the (european) day As most of my development environment is at work, and I'd prefer to spend work time on this 12:03:00 mattock 12:03:02 the majority of community devs are in Europe, so that makes sense jamesyonan 12:03:11 next week at this time would work for me mattock 12:03:28 I'm also now in California, so next week + european time is pretty bad for me jamesyonan 12:03:40 but I'm in US so European day is very early here dazo 12:03:41 andj: yeah, unfortunately jamesyonan is in California .... and he's our lead jamesyonan: have you ever considered to relocate to Europe? 12:04:07 (only kidding, of course) 12:04:21 jamesyonan 12:04:29 I do like Europe dazo 12:04:36 mattock 12:04:40 which country especially? dazo 12:04:56 mattock: that's so daring, it's almost rude!! andj 12:04:59 18:00 UTC is 20:00 here, could we start a little earlier, say at 15:00 or 16:00 UTC? jamesyonan 12:05:05 I've been to Sweden, Switzerland, Italy mattock 12:05:26 and Finland, actually if I recall correctly 12:05:32 jamesyonan 12:05:33 I walked into Italy once over the mountains from Switzerland dazo 12:05:43 nice jamesyonan 12:06:28 right -- took the train once from St. Petersburg to Helsinki ecrist 12:07:13 I've looked at maps of Europe... mattock 12:07:21 ecrist: that's a good start 12:07:30 raidz 12:07:34 HAHA ecrist 12:07:47 realized I can't bring my guns into most places, though mattock 12:08:09 anyways, I'd say that we should try to arrange at least part of the sprints in European time dazo 12:08:11 ecrist: it's only rednecks who believe you need guns in Europe .... dazo hides 12:08 jamesyonan 12:08:33 but these days I'm so swamped with work that probably the easiest way for me to be on European time is to work all night ecrist notes color of his neck, wonders what the problem is. 12:08 andj 12:08:40 mattock: finding a good compromise is fine, but 20:00 is a listtle late mattock 12:08:45 +1 dazo 12:08:56 +1 mattock 12:09:07 jamesyonan: what if we make case-by-case decisions? if it's clear we need your input, let's arrange them around this time 12:09:25 andj 12:09:28 which is why I would like to start a little earlier this time, as I think we have a lot of ground to cover so 1 or two hours earlier? 12:09:43 mattock 12:10:05 that would be better for me, too dazo 12:10:13 yeah, that makes sense andj 12:10:30 which would make it 18:00 UTC = 9:00 PDT? mattock 12:10:53 18:00 UTC is 11:00 PST (California time) jamesyonan: what's your timezone? 12:11:13 ecrist 12:11:17 1800 UTC is 1PM CST dazo 12:11:17 I'm just afraid of 2 hours before ... as that would easily slid into 3 hours meetings (2h reviewing + 1h meeting) ... that can be exhaustive, and I doubt it would make my wife happy mattock 12:11:51 we can cut them short and setup another sprint? I think 2 hours is about the max 12:12:27 dazo 12:12:28 if we decide 1h only sprint + max 1h meeting ... them I'm fine ... if it's a break in between or not, that's okay yeah, more fries my head, after having had 8 hours at work 12:12:46 mattock 12:13:00 also, sprints take over some of the "functionality" of the meetings so meetings should be shorter 12:13:04 jamesyonan 12:13:14 I'm usually on MST, which is one hour later than California time andj 12:13:52 Sure, let's just start with Thursday then, I've put in my 2 cents about the time, and will follow when others have time mattock 12:14:20 next meeting/sprint starting at 17:00 UTC next Thursday? ok for everyone? 12:14:26 andj 12:14:34 sounds good dazo 12:14:34 fine for me! jamesyonan 12:14:41 works for me mattock 12:14:45 and in the future, we can arrange ad hoc sprints in european time, unless James' input is needed dazo 12:14:54 sounds good mattock 12:14:59 which may not be the case every time ok, I think we've covered a lot today 12:15:08 anything else? 12:15:10 I assume there's no solution to the Win7 DHCP NAK bomb issue? 12:15:28 dazo 12:16:09 we need to catch up on janjust on that one ... I think he dropped the ball due to holiday season or so ... I think it's been quite quiet from him lately (esp. here on IRC) mattock 12:16:27 ok ok, if there's nothing else, let's call this a day 12:17:16 I can actually write summary now, it's only 12:17 here 12:17:31 (after lunch, probably) 12:17:38 see you later, guys! 12:18:11 andj 12:18:28 Thanks, see you! dazo 12:18:32 perfect! thanks a lot, everyone! 12:18:37 jamesyonan 12:18:38 take care andj 12:19:11 and let me know if you find anything/need anything befor that
