Here's the summary of the IRC meeting.



Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 5th December 2018
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:


The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



cron2, dazo, mattock, ordex, plaisthos and syzzer participated in this


Talked about OpenVPN T-shirts. Mattock has contacted various active
community members and asked if they want T-shirts. Once all have
responded mattock will place the order. For cases where shipping the
T-shirts from Finland would be challenging (import/export restrictions)
mattock will provide gift coupons instead.


Talked about buildslaves. Mattock will not migrate the following ones to
his updated home server as they're all EOL:

- ubuntu-1204-amd64
- debian-7-i386
- fedora-24-amd64

Mattock will create two new VMs to replace the above:

- ubuntu-1804-amd64
- fedora-29-amd64

Cron2 is working on a FreeBSD 12 buildslave.

It was agreed that having ARM64 version of FreeBSD as well as Linux,
e.g. on Raspberry Pi3 would be useful.


Discussed the option of using tags such as "tlscryptv2" to make "git
describe" output more human-friendly. Agreed that tagging the commit
that changes the version in version.m4 is reasonable.


Discussed rate-limiting of unauthorized incoming packets. Noted that
while tls-auth/tls-crypt solve the problem, there are cases where it
does not help:

- Large setups which can't easily migrate to either easi
- VPN providers who cannot trust their users

Tls-crypt-v2 is the long-term solution for the problem. Agreed that we
need to investigate how difficult adding rate limiting would be. After
that we can resume this discussion.


Talked about tap-windows6 HLK testing. Stephen Stair is working on it,
and it looks promising, though there has not been much progress since
the previous meeting last week. We will soon have to ask for updates.


Discuss networking API patch. No updates since last week.


Reviewed OpenVPN 2.5 status. MSI work is progressing well, but the
testing it is somewhat challenging because it requires a multi-machine
setup (Linux, Windows) with Samba shares. Mattock is working on it.

The rest of the release does not look so bright due to review delays
(see below).


Talked about the problem of patches getting stuck in "waiting for review
/ in review" state. Agreed to start assigning patches to people when it
is clear who is responsible. Also agreed to do weekly hacking sessions
(on Fridays) to help reduce the rather large review delays.


Full chatlog attached.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

(11:07:04) L'argomento di #openvpn-meeting è: Next meeting on 24/Oct/2018 at 
11:30CEST. Agenda at 
(11:07:04) L'argomento per #openvpn-meeting è stato impostato da 
ordex!~linux...@open-mesh.org/batman/ordex a 12:31:58 su 24/10/2018
(12:32:53) syzzer: meeting time?
(12:33:59) lev__: hello
(12:34:38) cron2: yes
(12:34:57) mattock: hi
(12:34:58) cron2: someone needs to wake up mattock, ordex, dazo, plaisthos...
(12:35:00) cron2: ah!
(12:35:25) mattock: I made it!
(12:35:43) syzzer: wow :D
(12:36:08) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2018-12-05
(12:36:09) vpnHelper: Title: Topics-2018-12-05 – OpenVPN Community (at 
(12:36:19) mattock: I have a topic to add, just a sec
(12:36:37) mattock: cron2's favorite
(12:36:43) mattock: T-shirts
(12:37:17) cron2: moar topics
(12:37:20) mattock: so I've been asking some people active in the community if 
they want t-shirts 
(12:37:22) mattock: most do
(12:37:28) cron2: *like*
(12:37:33) cron2: (well, both)
(12:37:42) mattock: once I get yes or no from them I will start the order 
(12:37:56) cron2: \o/
(12:38:04) mattock: in some cases I will probably buy them a gift coupon (e.g. 
if sending t-shirts from Finland would be tricky)
(12:38:10) cron2: (indeed, my favourite topic, and I will get into trouble with 
my wife)
(12:38:24) mattock: you wear the OpenVPN T-shirts too much? :P
(12:38:42) cron2: no, I have too many t-shirts, so the wardrobe overflows
(12:38:52) syzzer: :')
(12:38:57) mattock: ah
(12:39:03) mattock: ok, but that's all about the T-shirts
(12:39:26) mattock: topic #2?
(12:39:26) cron2: let's do 2. later (when dazo shows up)
(12:39:29) mattock: ah
(12:39:30) mattock: ok
(12:39:41) mattock: #3 buildslaves then
(12:39:59) mattock: so, I plan to discontinue a few of them
(12:40:08) mattock: ubuntu-1204-amd64, debian-7 and fedora-24-amd64
(12:40:12) mattock: any objections?
(12:40:18) ***plaisthos is woken up
(12:40:34) mattock: all are EOL (except ubuntu 12.04 which might still be 
barely alive)
(12:40:40) mattock: not sure
(12:40:55) ***ordex is here but quite busy
(12:41:36) mattock: ubuntu 12.04 is EOL
(12:41:41) mattock: anyways, those will go
(12:41:46) mattock: won't migrate them to my new home server
(12:42:00) mattock: but to compensate I will setup a few new ones: 
ubuntu-1804-amd64 and fedora-29-amd64
(12:42:26) mattock: those two are ready except for the actual buildslave config 
which may require some changes to puppet modules that setup buildbot
(12:43:01) mattock: the old, non-decommissioned buildslaves are running but 
have not checked if they actually work
(12:43:15) mattock: any comments/questions or shall we move on?
(12:44:07) cron2: I'll just add that I'll setup a FreeBSD 12 buildslave 
"soonish" (release is next week or so)
(12:44:18) cron2: and then review the freebsd zoo to see which ones can go
(12:44:47) cron2: (and I still want the PI3 to do an ARM64/FreeBSD buildslave, 
but that's taking time which is not there)
(12:45:17) mattock: ah that would be nice
(12:45:35) mattock: in fact it would be good to have ARM64 Linux as well
(12:45:45) mattock: I have a PI3 but it is doing other stuff
(12:46:44) mattock: now that dazo is semi-present, what about git tags?
(12:46:46) mattock: #2
(12:47:38) cron2: this was triggered by plaisthos yesterday, trying to make 
sense out of "git describe"
(12:47:41) cron2: which is now
(12:47:46) cron2: v2.4_rc2-400-ge11d2d14
(12:48:27) cron2: so the question is "do we want to regularily tag master with 
something that servers as a base for humans to give an idea how old/recent a 
certain commit is"
(12:48:45) cron2: (or, more specifically, how old a *build* might be that you 
encounter in a log file, etc)
(12:49:33) mattock: this would show up in "openvpn --version"
(12:49:34) mattock: ?
(12:49:41) cron2: it might
(12:49:53) cron2: (if we want it to) :)
(12:50:48) plaisthos: I probably otherwise just tag the branching point in my 
repo with v2.5-master
(12:50:57) plaisthos: so I get a nicer looking version in my app
(12:52:52) syzzer: I think what plaisthos says makes more sense
(12:53:29) syzzer: just add a tag right after branching out, something like 
v2.5-unstable or v2.5-master or so
(12:53:55) plaisthos: which is more complicated here since it is the same as 
(12:54:10) plaisthos: so git might pick up one or the other, right?
(12:54:43) syzzer: it picks the most recent tag
(12:54:55) plaisthos: okay
(12:55:09) cron2: what about v2.5-master-201811 or something like that?
(12:55:24) cron2: just throwing ideas around that might or might not be useful
(12:55:53) syzzer: cron2: why the date?
(12:56:18) cron2: you have "$tag-<number>" for "so many commits since $tag"
(12:56:45) cron2: so a date might give some idea "is this a recent build or 
based on 2016-ish master"
(12:57:13) plaisthos: cron2: that would only work if we tag frequently
(12:57:28) plaisthos: I think just one tag that points out the branching point 
is better for us
(12:57:30) cron2: yes, that is part of the discussion :)
(12:57:42) plaisthos: or we do semantic tags
(12:57:53) syzzer: what is semantic tags?
(12:58:04) plaisthos: like v2.5-master-tlscryptv2
(12:58:17) plaisthos: but it becomes then a bikeshed dicussion what changes 
require a tag
(12:58:30) syzzer: for me personally, just tagging the branching point suffices
(12:59:06) plaisthos: I am confused by git:
(12:59:09) plaisthos: [11:58]arne@styx:main/cpp/openvpn% git merge-base 
icsopenvpn openvpn/release/2.4  
(12:59:12) plaisthos: a5ae0138eed240a23f46c0f091f1830ab36396c2
(12:59:14) plaisthos: [11:58]arne@styx:main/cpp/openvpn% git show-ref --tags 
|grep a5ae0                
(12:59:17) plaisthos: a5ae0138eed240a23f46c0f091f1830ab36396c2 
(12:59:20) plaisthos: [11:58]arne@styx:main/cpp/openvpn% git describe           
(12:59:22) plaisthos: v2.4_rc2-410-gbb481e41
(12:59:55) syzzer: but didn't you now place the v2.4_rc2 and v2.5-master tags 
on the same commit?
(13:00:38) plaisthos: no, I got confused by a5ae0 commit message which is:  
Preparing OpenVPN v2.4_rc2 release
(13:01:21) plaisthos: the tag  v2.4_rc2 actually points to a different commit
(13:01:22) syzzer: I think e1dd49a3 should just get a tag that matches 
(13:02:37) syzzer: I'll have to leave in a few minutes to catch a plane btw
(13:03:52) mattock: have we reached a consensus?
(13:04:27) syzzer: not sure, I've just been giving my opinion so far :p
(13:04:29) mattock: tagging the branching point?
(13:04:37) mattock: anyone objects to that? :P
(13:05:11) syzzer: more specificatlly, I propose "Tagging the commit that 
changes the version in version.m4"
(13:05:23) mattock: ok
(13:05:31) mattock: makes sense
(13:05:53) cron2: ok
(13:05:58) cron2: I can live with that
(13:06:52) plaisthos: sounds good
(13:07:11) mattock: move on?
(13:07:33) mattock: we all have our lunches to eat :P
(13:07:37) mattock: or planes to catch
(13:07:44) cron2: while syzzer is still here, can we quicky cover 6.?
(13:07:50) mattock: definitely
(13:07:58) mattock: OpenVPN 2.5 status 
(13:08:21) syzzer: or rate-limit?
(13:08:24) cron2: rate-limit
(13:08:33) plaisthos: I think rate limit incoming packets is not a big issue
(13:08:35) mattock: oh yes
(13:08:38) mattock: topic list was updated
(13:08:49) plaisthos: if it is an issue for you, use 
(13:09:10) syzzer: I read along on the ml, and think our answer should probably 
just be "use tls-auth/crypt/crypt-v2"
(13:09:46) cron2: it is a big issue, since we're not enforcing tls-auth/crypt 
and people have large deployed configs that can't be moved to tls-auth over 
(13:10:00) cron2: (also, it's an issue for large VPN providers that *use* 
tls-auth but have a malicious customer)
(13:10:08) mattock: that one indeed
(13:10:15) syzzer: that's where tls-crypt-v2 should help :)
(13:10:23) plaisthos: for large VPN provider then tls-crypt-v2 is the answer
(13:10:35) plaisthos: syzzer: can you actually revoke client keys?
(13:10:41) syzzer: plaisthos: yes
(13:10:49) cron2: tls-crypt-v2 is the long-term answer, but not short term
(13:10:59) syzzer: oh, *but* only after the third packets...
(13:11:24) syzzer: because the actual revocation checking is a burden on the 
server itself
(13:11:34) syzzer: so is only done after the first three-way handshake
(13:11:46) syzzer: oh, but I now really have to leave
(13:11:52) syzzer: I think this over a bit more
(13:11:53) plaisthos: bye
(13:11:56) mattock: bye!
(13:13:11) mattock: so how big a can of worms is implementing rate limiting?
(13:13:17) mattock: "should we go there"
(13:13:39) plaisthos: probably a lot of work 
(13:13:45) cron2: I have no idea because I'm not sure how much magic James has 
already provided
(13:13:56) cron2: we have hashes, timers, events
(13:14:01) plaisthos: and only benefits those large VPN providers
(13:14:23) plaisthos: everyone else should be fine with tls-auth/tls-crypt(-v2)
(13:14:31) cron2: you have seen more client configs than we have - what's the 
percentage of tls-auth-using VPNs out there?
(13:14:50) plaisthos: OpenVPN AS uses it by default
(13:15:05) plaisthos: for the rest depends on what tutorial people used
(13:15:16) plaisthos: some even if the same tls-auth key as in the tutorial :D
(13:15:42) mattock: you mean the VPN providers setup their servers with 
tls-auth keys from a tutorial :P ?
(13:16:06) plaisthos: no for your home run vpn server
(13:16:15) mattock: I thought so
(13:16:27) plaisthos: but considering that there is *still* a VPN provider with 
MD5 certificates I would not bet against you
(13:16:28) mattock: cron2 was specifically asking for client configs from VPN 
(13:16:40) cron2: not particularily, just "configs"
(13:16:53) mattock: ah
(13:16:59) mattock: well anyways
(13:17:12) mattock: 13 minutes left
(13:18:34) plaisthos: for most home use VPN configs the normal DOS will 
saturate your bandwidth and you are dead anyway *shrugs*
(13:18:34) cron2: the point is reflection, throw packets at other people
(13:21:08) mattock: as for implementation: "need to investigate more"?
(13:21:17) cron2: definitely :)
(13:21:39) mattock: continue discussion after more investigation?
(13:22:21) cron2: yep.  leave on agenda for next week, then see if we want/can 
do something
(13:22:24) mattock: ok
(13:22:35) mattock: I propose #5 tap-windows6 because it is fast
(13:22:44) cron2: I was about to say that :)
(13:22:46) mattock: "not much has happened, will soon have to ask Stephen"
(13:23:57) cron2: on 4., no updates either
(13:24:02) mattock: that was fash
(13:24:04) mattock: fast
(13:24:12) cron2: which brings us to 7., and that's also not very satisfying
(13:24:31) mattock: OpenVPN 2.5 status
(13:24:53) mattock: rozmansi and selva have worked on it actively
(13:25:07) mattock: I'm in the process of testing the MSI packaging, but stuff 
keep getting in the way
(13:25:25) mattock: it involves a two-machine setup (one linux, one windows) 
with samba shares
(13:25:33) mattock: so it is more complicated than what we had previously
(13:25:37) cron2: haven't seen anything from Selva - was that off-list?
(13:25:42) mattock: in the PR
(13:25:44) mattock: openvpn-build
(13:25:45) cron2: ah
(13:26:14) mattock: rozmansi's changes are very large, so it just needs to be 
tested to see if there are any glitches
(13:26:28) cron2: I can merge the openvpnmsica patch set if you say "it's 
working" - we haven't seen an ACK or LGTM on the *first* patch of the series, 
though, which is the biggest hunk...
(13:26:51) mattock: I did build-test the patch that added tapctl.exe and the 
MSI custom action
(13:26:54) cron2: it's not "openvpn code", but it's "runs privileged on windows 
code", so it needs a bit of review, at least
(13:27:24) mattock: but I think we can wait until the test setup is ready, so 
that the whole build stack can be tested
(13:27:47) mattock: what about the "other stuff" in OpenVPN 2.5?
(13:27:53) cron2: this is at least some good news :-) - the rest is more 
(13:27:58) cron2: we have about 100 patches in patchwork, and once a week (or 
even more infrequent) someone speaks up and complains about coding style...
(13:28:16) mattock: review issues that is?
(13:28:28) cron2: so our ACKs are working even less well than usual
(13:28:59) mattock: maybe have these meetings weekly so that we can get to the 
last topic ("review patches in patchwork")?
(13:29:10) mattock: maybe even pick some patches from patchwork to focus on
(13:29:24) cron2: we do have weekly meetings, even though you're not always 
here :-)
(13:29:29) mattock: lol yes
(13:29:34) mattock: the first time I believe I forgot to join
(13:29:49) mattock: now I will hear about it for the rest of my life :D
(13:30:31) mattock: but we could pick some patches as separate topics
(13:30:37) cron2: not sure the meeting is the right place to increase our 
agility here ("ah, I could do a review now, but I can do it next wednesday, so 
let's wait for the meeting")
(13:30:55) mattock: that is a risk yes
(13:31:38) mattock: though I'm not sure what the best solution would be
(13:31:41) cron2: so, ordex, plaisthos, dazo: how can we improve?
(13:32:38) mattock: my worry is that internal development is taking (arguably) 
too much time from ordex, plaisthos and dazo
(13:32:44) ordex: sorry if I am not here for real today - just very busy .-.
(13:33:01) ordex: what do we want to "improve" exactly? review effort?
(13:33:20) mattock: patches get stuck in review
(13:33:23) cron2: improve the "patch is out there for four weeks, and then 
there is a review complaing about style, and then nothing ever again" cycle
(13:33:34) ordex: yeah
(13:34:05) ordex: I think currently we have very complex patches out there and 
often very big, so just doing context switch to review requires quite some time 
at every cycle
(13:34:11) cron2: focusing on style is ok, but I think the review should at 
least cover the technical merits as well, so "if the style is fixed, it has my 
ACK" can really help move forward
(13:34:30) ordex: cron2: yeah, that's true
(13:34:41) ordex: it's just that sometimes it is better to do style review 
rather than nothing at all :p
(13:34:43) ordex: but I agree
(13:34:56) cron2: I'm not sure if a sole style complaint is better than 
"nothing at all"
(13:35:20) ordex: I am just use to the old rude rule "if style is not proper, I 
won't even check your patch"
(13:35:26) cron2: if I send a patch to the list, nothing happens for four 
weeks, and then I get back a "your coding style sucks" mail - do you think I'll 
be motivated to send a v2 like the next day?
(13:35:50) cron2: now if the coding style complaint comes in like "5 minutes 
after the patch hits the list" - that's something different
(13:36:00) ordex: cron2: well, if my time is so little that I could only spend 
it to review the poor style, that it really means the writer wasted my time to 
be honest
(13:36:11) ordex: *then
(13:36:34) dazo: Can we "fix" this by just running uncrustify on commit time 
when there are code style complaints?
(13:36:35) ordex: nonetheless I agree that making everything faster would be 
(13:36:50) cron2: dazo: that's what we already agreed that we want to do :-)
(13:36:58) ordex: yeah, having an automatic style checker would definitely 
improve this, but we did not get there yet
(13:37:06) cron2: (and this is why I sent 3 uncrustify patches last saturday 
which nobody showed an interest in...)
(13:37:18) ordex: still, if after setting this rule we get patches with style 
mistakes, they really won't deserve any review :-P
(13:37:22) ordex: yeah :(
(13:37:35) mattock: if there is a technical solution to the style problems 
let's by all means implement it a.s.a.p.
(13:37:35) cron2: ordex: plaisthos' found the tool online, you just need to use 
it - since this is something that needs to be done locally
(13:37:57) cron2: "run uncrustify in the local pre-commit-check", at least 
those from the core team that do large patch sets
(13:38:12) ordex: yap
(13:38:13) plaisthos: I think for non core members we can be a bit more reliant 
and run uncrustify for them but for core members we can enforce clean patches
(13:38:17) cron2: for a first-time submitter, be gentle and accepting (and 
possibly uncrustify on merge)
(13:38:26) dazo: yes ... but ... still, this is actually just side-tracking the 
real problem .... most of us are just far too busy :/
(13:38:43) dazo: agreed
(13:39:13) ***cron2 can do merges in 5 minutes "at any times" - if I have an 
(13:39:38) ordex: I think it's the ACK that requires 5^n minutes :D
(13:39:47) dazo: yupp
(13:39:54) cron2: (and this is actually something that nicely fits in between 
feeding kids, bringing them to bed, et.c)
(13:40:35) cron2: but I can't review windows patches, build system patches, tap 
driver patches, networking patches, crypto patches, etc. all by myself
(13:41:00) cron2: anyway
(13:41:23) mattock: so how do we set aside time to do patch review?
(13:41:39) cron2: what we need to come to acceptance, I think, is that we're 
not going to make "end of december" with 2.5 - if we can agree that this is 
acceptable, we can just move forward as time permits
(13:41:55) ordex: openvpn inc is already willing to "sponsor" some hours every 
week to do review or community work in general
(13:42:15) mattock: they ought to :P
(13:42:22) ordex: but the issue is really allocating time
(13:42:29) cron2: so I have heard at the hackathon, but it hasn't materialized 
visibly yet :-)
(13:42:35) mattock: +1
(13:42:43) dazo: From a personal perspective .... I'm dragged in two 
directions; paid work wants focus on openvpn3 related stuff - with its own 
deadline, but also understands the need to do openvpn2 community work .... and 
community work backlog is huge and taking a lot of efforts .... it is really 
hard for me to find a good balance here
(13:42:55) dazo: I agree, we can't make the 2.5 in december
(13:43:22) cron2: shall we re-try the idea with focused community work days?
(13:43:31) mattock: I'm also constantly pulled into different directions which 
makes it difficult to focus on community stuff
(13:43:42) mattock: cron2: I like that idea
(13:43:45) ordex: personally I'd need to integrate a bit more openvpn community 
effort into my project management schedule: i.e. at the moment I don't know 
what is waiting my review or what might be allocate don me. unless I spend 20 
minutes checking the mailing list (of course I remember stuff, but can't 
remember the exact patches to review)
(13:43:46) cron2: like, "Friday, cron2, ordex and plaisthos are *online*, and 
focus on quick turnarounds?"
(13:44:05) ordex: cron2: how would that work? we do review together ?
(13:44:24) ordex: if I';d get a number of patches allocated to me on PW I'd 
already be happier, because then I'd just go there and see my queue, for example
(13:44:26) cron2: ordex: one of the problems right now is the delays
(13:44:33) cron2: plaisthos sends a patch
(13:44:38) cron2: you review it 5 days later
(13:44:44) cron2: plaisthos sends a v2 after a week
(13:44:49) cron2: you review it a week later
(13:44:51) cron2: plaisthos sends a v3 after a week
(13:44:56) cron2: ... a month lost
(13:45:10) ordex: yap
(13:45:12) ordex: true
(13:45:18) cron2: so if we can be online and active at the same time, we can 
discuss technical questions on IRC "in real time"
(13:45:44) cron2: like, "so, I try <this> and it does <that>, is that 
intentional?" and get back a "oh, I'll send a v4 right away" or "yes, it's in 
the manpage"
(13:46:08) dazo: mattock1: aren't you doing some live internal hacking sessions 
with Justin, via appear.in?   If so, what's the experience here?
(13:46:19) cron2: and stuff like style review or typos can be fixed for good 
because it's like "there is still something wrong here" - "ok, I#ll send a v4!"
(13:46:59) dazo: we could try to do something similar, to have at least an 
audio channel open during these sessions .... as in a virtual meeting room when 
working our way through the patches
(13:47:01) cron2: not sure we need audio/video conferencing, but "being present 
and responsive" is what ismissing
(13:47:20) dazo: but it's harder to "hide" when you have that channel open ;-)
(13:47:49) dazo: kinda like an ad-hoc online hackathon 
(13:47:59) ordex: to be honest, I think the problem is just motivation. I speak 
to plaisthos everyday basically, so I can get quick response from him in a very 
reasonable time. the point is that "it is never good time to do community stuff"
(13:48:16) ordex: so this gets always pushed to later
(13:48:33) cron2: ordex: so, shall we arrange for chocolate to send your way, 
to increase motivation? :-)
(13:48:36) ordex: and "forcing ourselves" to be present at the same time to do 
community stuff might work a couple of times
(13:48:37) ordex: haha
(13:48:38) ordex: :D
(13:48:40) ordex: no thanks
(13:48:47) mattock: dazo: yes I do have sessions with Justin and they work well 
(13:49:08) cron2: ordex: so, do you have an idea how to get moving again?
(13:49:36) plaisthos: I am also not always in the mood or can concentrate well 
enough to review patches
(13:49:37) cron2: I'm not going to "force" anyone to anything (as that doesn't 
work for community stuff), just trying ideas
(13:49:53) ordex: cron2: personally, as I said before, for me it might work to 
get a task queue built up on my head: i.e. delegate patches to me on pw. I have 
an easy and quick way to check patches in my queue and I go through when I have 
time allocated
(13:49:58) cron2: plaisthos: coffee or chocolate your way?
(13:50:07) ordex: yeah, this is why I used quotes :)
(13:50:09) plaisthos: coffee does not work on me :P
(13:50:15) ordex: hehe
(13:50:16) cron2: plaisthos: rum?
(13:50:22) plaisthos: cron2: tea ;)
(13:50:22) ordex: <o>
(13:50:43) cron2: (looking at some of the patches, I'm sure Alcohol must have 
been involved... :) )
(13:50:46) plaisthos: but having a view in patchworks that is assigned to me 
and uassigned patches would really help
(13:50:47) mattock: I think we should try cron2's suggestion unless somebody 
has better ideas
(13:51:15) plaisthos: I have far too often spend like 10 minutes to figure out 
what to review next in patchworks and then given up
(13:51:19) ordex: cron2: how about going through the patches in pw and delegate 
to me what you believe I should review because .. it falls under something i 
can understand?
(13:51:22) cron2: we didn't "assign" stuff in patchwork so far because *I* do 
not like that :-) - but if you're ok with it, I can try that
(13:51:42) ordex: cron2: yeah, each of us has his own way, not saying it will 
work for everybody :)
(13:52:03) ordex: mattock1: that is? being online on friday night on IRC doing 
code review? :D
(13:52:23) cron2: ok, I'll try to assign a few things tonight, to see if that 
works out
(13:52:39) cron2: what about "v1 of the patch was sent, got back a comment, and 
then nothing" stalemates?
(13:52:43) mattock: ordex: for example yes
(13:52:51) mattock: we can start with assigning patches though
(13:52:59) mattock: to see if that actually helps
(13:53:15) mattock: I need to go eat lunch
(13:53:18) ordex: cron2: yeah, I hope that would follow once the work is more 
(13:53:23) ordex: oky
(13:53:29) mattock: consensus: "will start assigning patches in patchwork"?
(13:53:34) dazo: mattock1 and I have a meeting this Friday evening (19:00 CET) 
... but otherwise, I think it's a good idea ... I can normally allocate times 
on Fridays unless there are deadlines we're trying to reach.
(13:53:45) dazo: mattock1: +1
(13:53:50) mattock: ok
(13:54:08) cron2: I'll do a few tonight, and we see how it works.  I'll be 
around on Friday after about 10 am to 6 pm local time
(13:54:25) dazo: I think it makes sense to assign patches in patchwork when 
there's a clearly defined person with the required skills to bring it forward
(13:55:00) mattock: done for today?
(13:55:08) cron2: totally so
(13:55:12) mattock: \o/
(13:55:12) ***cron2 needs coffee :)
(13:55:15) dazo: And I'll try to get the openvpn3-linux beta release 
out-the-door today, which hopefully will give me some more flexibility in the 
near future
(13:55:18) mattock: let's get the train moving forward again
(13:55:20) cron2: but I think we have a way forward
(13:55:21) cron2: yes
(13:55:29) mattock: "Make OpenVPN 2.x development great again!"
(13:55:31) plaisthos: I will push openssl 1.1.1 on my app users :P
(13:55:45) cron2: I'll start with assigning the uncrustify patches to ordex, 
they should be to his liking :)
(13:55:50) ordex: :)

Attachment: signature.asc
Description: OpenPGP digital signature

Openvpn-devel mailing list

Reply via email to