Here's the summary of the IRC meeting.



Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 1st Nov 2017
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


Discussed how to make testing of unmerged patches easier. While pushing
the patches through buildbot would be optimal, buildslaves run with root
privileges. Hence this approach would be limited to trusted developers.

It was thus decided to tackle this problem with Vagrant, which has base
boxes for all/most operating systems we have in buildbot:


The benefit with Vagrant is that anyone, including untrusted developers,
will be able to use it for testing their patches on other, possibly
esoteric, platforms.

We will start by providing a proof-of-concept Vagrantfile that sets up
OpenVPN build environments on a couple of operating systems, then build
on top of that work. Mattock will try to have the PoC ready by the
hackathon (i.e. late next week).

At this point it also makes sense to take a second look at the existing
Vagrant pull request in here:


It got stuck primarily due to a few bashisms.


Discussed our "oldstable" support policy. It was agreed that we do _not_
want to support "oldstable" and "stable" until "stable+1" is released.
Or, in other words, support two stable releases at all times.

We will work on defining an EOL policy for future releases on this page:


It was agreed that 2.3.19 will be the last 2.3 release for which we will
build Windows installers and Debian packages. Subsequent releases of 2.3
will be source-only, and at some point support for 2.3 will be dropped
altogether. Source-only release means that we will provide signed
tarballs but no installers/packages.

That said, if particularly nasty security issues arise we will consider
providing updated installers and packages even for source-only releases.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

(12:28:07) mattock: meeting in 2 minutes
(12:28:17) dazo: good morning :)
(12:28:27) mattock: afternoon :)
(12:28:33) ordex: :D
(12:28:33) mattock: literally
(12:28:39) cron2: mattock: which time zone are you in, right now?
(12:28:43) cron2: UTC+2?
(12:30:30) syzzer: morning :)
(12:30:56) cron2: train connections from munich to karlsruhe suck
(12:31:21) mattock: let's begin
(12:31:36) ordex: sure
(12:31:45) cron2: go!
(12:32:13) dazo ha scelto come argomento: Meeting 2017-11-01 11:30 CET: Agenda 
at https://community.openvpn.net/openvpn/wiki/Topics-2017-11-01
(12:32:26) mattock: ah, good
(12:32:33) mattock: topic #1
(12:32:58) mattock: "Test branches on github, targeting buildslaves"
(12:33:09) cron2: here's a recap of the problem statement: "someone who is not 
me is working on something that might break strange platforms, how to test for 
(12:33:34) syzzer: yes plz!
(12:33:35) cron2: (I can just log into my buildslaves and test :-) - but maybe 
we can use buildbot to do it)
(12:33:35) mattock: buildbot is definitely the best candidate
(12:33:35) dazo: just thinking aloud ... is it possible to have a host a 
tarball can be pushed to, which gets configured and built by the buildslaves?
(12:34:00) mattock: dazo: possibly
(12:34:13) mattock: another option would an "experimental" branch where we 
would just rewrite history as we please
(12:34:19) cron2: another idea that came to me just now is "I could open up the 
buildslaves to trusted users" (because in the end it does not matter if I give 
you build access, or buildbot can run things as root that you put into a 
(12:34:20) dazo: that would probably be easier to manage than "everyone" can 
push to this git repo
(12:34:34) ordex: pushing a tarball or a branch sounds similar. the question 
is: how often can we do this? and can everybody do that unconditionally?
(12:34:57) ordex: or we want to limit one person to be able to push the tarball 
(12:34:58) cron2: ordex: most definitely not "everybody"
(12:35:03) mattock: ordex: only those we trust, because otherwise people could 
make buildbot do pretty much anything
(12:35:16) dazo: I was thinking along the lines of ssh/sftp ... where only 
trusted and vetted users gets access
(12:35:25) dazo: (typically us core developers)
(12:35:34) ordex: yep that is reasonable. that can be done on git hub, no? 
maybe with a new repo where only few people have access
(12:35:37) cron2: since the t_client tests run the freshly built openvpn 
executable with sudo, this is full system compromise :-)
(12:35:45) ordex: eheh
(12:35:54) syzzer: how flexible is buildbot? Isn't it better to just e.g. let 
is build the "buildbot" branch of maintainer's private gh repos?
(12:36:07) ordex: +1
(12:36:13) mattock: it is very flexible
(12:36:14) syzzer: that would not clutter the core repo
(12:36:18) ordex: maybe once a day is there is something new
(12:36:19) dazo: agreed
(12:36:23) ordex: *if
(12:36:39) mattock: as long as these special builds are triggered manually 
having additional repositories configured should be fine 
(12:36:40) cron2: once per day is too slow if you've just found out that you 
broke NetBSD, FreeBSD *and* OpenBSD, and want to test fixes
(12:36:47) dazo: +1
(12:36:57) cron2: mattock: ah, good.  I thought you are limited to "one repo, 
but can select branches"
(12:37:06) ordex: cron2: how long does a full run take?
(12:37:19) mattock: no, I don't think so, buildbot is just Python so we can do 
pretty much anything we want
(12:37:19) cron2: ~20 minutes if you build all variants
(12:37:30) mattock: in the worst case setup a second buildmaster instance to a 
different port
(12:37:30) ordex: if it takes not too long..then we could do it upon every 
push, like travis
(12:37:37) cron2: ordex: if you just want the "default options, t_client" test, 
maybe 5 minutes
(12:37:51) ordex: ah quite fast
(12:37:53) dazo: ordex: that's what we do now ... but only cron2 and I have 
commit/push privileges
(12:38:07) ordex: dazo: yup, and extending that with syzzer's idea seems quite 
good already, no?
(12:38:16) cron2: ordex: CPU *does* cost money, though...  so on a development 
repo which gets hacked on a lot, maybe not automatic on every push
(12:38:49) ordex: cron2: knowing that branch X is only for buildbot it's up to 
the dev responsibility to not abuse, I think (?)
(12:39:09) mattock: ordex: +1
(12:39:12) cron2: ordex: if you do it by branch, that would be similar to 
"manual start", right
(12:39:33) ordex: cron2: otherwise a hourly cronjob can check and build the 
special branches .. if this is better than "upon every push"
(12:39:51) ordex: but i think build on push is ok as soon as this is done 
(12:40:25) cron2: right (if I get a heavy bill, I'll forward this on...) :-)
(12:40:31) ordex: eheh
(12:40:33) dazo: but that branch can be quite ugly .... merge conflicts etc, 
(12:40:50) dazo: (if it is a shared branch, that is)
(12:40:51) ordex: dazo: it's your own private branch, you can just reset/rebase 
it every time
(12:40:55) cron2: my mental picture has a throwaway branch per user
(12:40:58) dazo: ahh, okay
(12:41:12) ordex: dazo: syzzer's idea was to have 1 branch per dev, in our own 
openvpn fork
(12:41:22) cron2: so either "github.com/dazo/openvpn" with branch "buildtest", 
or "github.com/openvpn" with branch "dazo-buildtest", or whatever
(12:41:28) ordex: right
(12:41:40) cron2: single-user branches
(12:41:46) cron2: (effectively)
(12:41:49) ordex: either one would work. probably the private fork is easier to 
handle from the permission perspective
(12:41:52) plaisthos: or add a private extra repo for that
(12:42:03) plaisthos: that only a special group in github is allowed to push to
(12:42:10) dazo: alright ... that can work .... I think assigning our 
private/user repos is better than a shared branch in the main openvpn repo 
(12:42:20) mattock: as a sidenote: we're going to be setting up an OpenVPN test 
server environment internally similar to t_client, and it will use Vagrant as 
well as a more long-running test instance
(12:42:20) ordex: yeah that too. but we have to tell buildbot each branch to 
build, so I guess telling it where the private branches are is easier
(12:42:27) cron2: however it can be done without too much friction...
(12:42:29) dazo: less chance of clutter if github explodes in badness
(12:42:34) ordex: yeah
(12:42:36) ordex: :D
(12:42:46) mattock: I did a quick check on which (virtualbox) boxes Vagrant has 
and there are plenty: https://app.vagrantup.com/boxes/search
(12:42:47) vpnHelper: Title: Discover Vagrant Boxes - Vagrant Cloud (at 
(12:42:59) mattock: freebsd, openbsd, solaris and probably all linuxes you can 
(12:43:25) mattock: the benefit with a Vagrant-based approach is that we don't 
have to trust any developer at all
(12:43:32) cron2: interesting
(12:43:37) dazo: oh ... on the test server side .... I've recently gotten 
allocated (for free) 2 VMs with Power8 running latest Fedora ... one in 
little-endian mode and the other one in big-endian
(12:43:43) mattock: giving anyone the possibility to test their code, not just 
us core devs
(12:43:59) mattock: ...on "funky" platforms I mean
(12:44:15) cron2: mattock: true.  Could you get us feedback how the deployment 
works, and how expensive it is, per "make test" run?
(12:44:23) dazo: mattock: nah, even with vagrant you expose network and CPU to 
"unknown" users
(12:44:35) cron2: dazo: well, the point is that "the unknown user" runs vagrant 
(12:44:46) mattock: dazo: I'm talking about the unknown users running the tests 
(12:44:50) mattock: exactly
(12:44:57) dazo: ahh, right ... okay, that's safer :)
(12:45:00) cron2: like, ordex wants to test on FreeBSD, so he fires up vagrant 
(12:45:02) mattock: we're not exposing anything to unknown people :)
(12:45:10) dazo: good! :)
(12:45:29) cron2: what worries me a bit is that this will create quite a bit of 
support overhead ("what do I need to do to a FreeBSD build to make openvpn 
build and run t_client?")
(12:45:46) mattock: the cost would mostly be memory and CPU at their end, if 
they want to run a full test suite similar to buildbot
(12:45:47) cron2: so, happy to hear about your experiences, mattock :)
(12:46:10) mattock: that won't be a problem
(12:46:14) mattock: so this is how Vagrant works
(12:46:26) mattock: it takes a base box (e.g. debian, openbsd)
(12:46:39) mattock: it creates a virtual machine based on that box (=vm image)
(12:46:58) mattock: it then "provisions" the box using scripts, ansible, puppet 
or whatnot
(12:47:01) mattock: generally scripts
(12:47:14) mattock: so the provisioning part would be used to ensure that 
OpenVPN builds on that particular box
(12:47:36) cron2: so, guess who gets to maintain these provisioning scripts for 
FreeBSD, NetBSD, OpenBSD, OpenSolaris, AIX, ...? :-)
(12:47:52) mattock: from user perspective the process would be
(12:47:52) mattock: - vagrant up openbsd-<something>
(12:47:52) mattock: - vagrant ssh openvpn-<something>
(12:47:57) mattock: then just build for that platform
(12:48:14) mattock: cron2: cron2?
(12:48:18) mattock: :P
(12:48:24) ordex: cron²
(12:48:33) cron2: which brings me back to "what worries me a bit is that this 
will create quite a bit of support overhead" :-)
(12:49:07) mattock: we do have a t_client + vagrant PR open on GitHub which has 
been lying there
(12:49:15) cron2: but it's certainly worth having a close look, also to see how 
fast the spinup/spindown of these VMs is - like, can you afford this for a 
general "make test" run?
(12:49:18) mattock: primarily due to it having bashisms
(12:49:41) mattock: cron2: you can provision the VMs once and then just shut 
them down
(12:49:48) mattock: bringing them up again cheap
(12:49:54) ordex: mattock: but we can assume vagrant will run on a reference 
linux platform
(12:49:59) mattock: although the full cycle is not very heavy
(12:50:14) mattock: a couple of minutes of VM setup
(12:50:18) mattock: per VM
(12:50:25) cron2: sounds good
(12:50:33) cron2: so... which way do we want to go?
(12:50:38) mattock: I think that from scratch one could run the full test suite 
in <30 minutes
(12:50:57) ordex: mattock: why 2 minutes to setup? it installs everything from 
scratch every time? there are no tVM snapshots?
(12:51:30) mattock: no, the base box is a VM image, but there's some overhead 
when creating the VM into e.g. virtualbox
(12:51:35) mattock: plus running the provisioning steps
(12:51:41) ordex: mh ok
(12:51:52) mattock: base box is assumed to be usable as-is
(12:52:00) ordex: usually kvm takes 3 to 5 seconds to boot from bootloader to 
(12:52:02) mattock: but the provisioning step is what makes it special
(12:52:07) ordex: I see
(12:52:08) mattock: yeah, to boot
(12:52:18) mattock: but this is about creating the VMs from a base VM image
(12:52:28) plaisthos: basically private travis :)
(12:52:28) mattock: but you don't need to destroy the Vagrant-created VM unless 
you want to
(12:52:36) syzzer: heh, some colleague just walked by towards lunch, noticed 
the Vagrant web page on my screen and started ranting :')
(12:52:36) ordex: understood
(12:52:43) ordex: lol
(12:53:11) syzzer: have to poke him later to figure out why he doesn't like it
(12:53:19) dazo: ordex: for recent Linux distros (often systemd based) 3-5 
seconds are right .... older and sys-v based approaches generally takes far 
(12:53:26) mattock: syzzer: I could also rant about it, but for this purpose it 
would probably be a good solution
(12:53:26) ordex: by the way, I think we should plan a short-term and a long 
term solution at this point?
(12:53:28) syzzer: he's a docker guy though, so is likely to call "just use 
(12:53:29) ***cron2 needs a bigger disk, more RAM, and more CPU :-)
(12:53:34) ordex: :D
(12:53:38) ordex: cron³
(12:53:43) mattock: syzzer: how would we docker openbsd and solaris? :P
(12:54:13) plaisthos: solaris has zones and whatever for ages
(12:54:16) syzzer: I dunno, I try to avoid the whole container mess :-p
(12:54:19) plaisthos: but linux reinvted the wheel
(12:54:22) mattock: anyways, I think we should do a PoC of Vagrant
(12:54:25) dazo: syzzer: docker works fine if you're just going to do builds on 
the same OS you're running locally .... but can't "boot" *bsd in a docker 
container on Linux :)
(12:54:26) cron2: +1
(12:54:38) plaisthos: also jails on bsd
(12:54:41) mattock: do we want just compile tests right now?
(12:54:54) dazo: I think compile tests is a good starting point
(12:55:02) cron2: well, compile test and local "make check" is a good starting 
point for general explosions
(12:55:05) cron2: then, t_client
(12:55:10) syzzer: yeah, that, "baby steps"
(12:55:30) cron2: (which obviously need some sort of defined process how you 
get t_client credentials and what to do or not to do with them)
(12:55:32) dazo: but ... mattock, correct me if I'm wrong .... with vagrant we 
can spin up more VMs at the same time?  one could be a VPN server?
(12:55:35) mattock: do we want the compile tests to be automatic when the VMs 
are brought up/provisioned?
(12:55:41) mattock: dazo: yes
(12:55:46) mattock: the PR on GitHub actually does that
(12:55:54) cron2: dazo: indeed, good point
(12:56:13) mattock: so we could start by setting up the "t_client clients" 
without the server
(12:56:15) mattock: for compile tests
(12:56:27) cron2: nevertheless, let's start small -> compile, local test.  Then 
refine for network tests.
(12:56:29) mattock: then later create t_client server(s) as separate VMs
(12:57:08) dazo: so ... first, get a vagrant setup to automatically compile a 
tarball or git checkout or whatever .... then spin off another vm and run 
connectivity tests.  That "another vm" can be the smallest image of any distro 
possible with a pre-installed VPN server binary
(12:57:30) dazo: or it can be the same base image, with the built binary copied 
(12:57:57) dazo: (both cases are relevant ... depending on what code paths you 
changed ... hard to debug issues if both sides changes)
(12:58:03) ordex: shouldn't we test the server on different platforms too? :S
(12:58:04) cron2: remind me to add a 2.3 server to my mix :)
(12:58:32) mattock: ordex: we should, but that would get complex quite fast :)
(12:58:33) cron2: ordex: if it compiles and local "make check" passes, usually 
server side is good as well
(12:58:36) dazo: ordex: well, true .... but server/client is essentially just a 
matter of "use this config" :)
(12:58:46) ordex: eheh okok
(12:59:09) cron2: there's a few tricky things with tap and installing routes 
and that, so when you start breaking all this, you want servers on all 
platforms, right
(12:59:13) ordex: was wondering about codepaths that are crossed only in server 
mode and that might be platform dependent. but this can be the very last concern
(12:59:44) dazo: yeah
(12:59:56) dazo: first .... compile/build images :)
(13:00:03) ordex: so, we skip the buildbot-branch idea at all and wait for 
vagrant directly?
(13:00:08) mattock: I think so
(13:00:20) syzzer: cron2: just created a reminder for you ;-)
(13:00:25) ordex: ok
(13:00:34) cron2: syzzer: what, where?
(13:00:38) syzzer: https://community.openvpn.net/openvpn/ticket/954
(13:00:41) cron2: ah
(13:00:43) vpnHelper: Title: #954 (Add a 2.3 server to the t_client test setup) 
– OpenVPN Community (at community.openvpn.net)
(13:00:54) cron2: thanks :)
(13:01:16) dazo: yeah, makes sense
(13:01:32) cron2: anyway, if one of you urgently wants to test something on one 
of the more strange platforms, feel free to send me a ssh pubkey and a source 
ip (range) where you connect from, and I'll get accounts done on my *BSD zoo
(13:01:34) syzzer: ok, so I think we have a plan for the coming week(s) ?
(13:01:36) ordex: ok, so topic #1 is addressed with vagrant
(13:01:39) cron2: yep
(13:01:47) mattock: yes
(13:01:58) mattock: #2 Revisit our support policy for "oldstable"
(13:02:02) ordex: mattock: this will take ~2 weeks ?
(13:02:05) ordex: just to have a rough idea
(13:02:07) cron2: plaisthos: can you bring an image of your MacOS X buildbot 
with you to Karlsruhe?
(13:02:09) ordex: also for the Inc side
(13:02:27) mattock: I think I can get a PoC done by hackathon
(13:02:35) ordex: cool
(13:02:49) mattock: I use Vagrant quite a bit, so it's mostly about "what has 
the priority"
(13:02:57) ordex: goed
(13:03:23) ordex: on the Inc side we really need to get the dev-test box 
started because we are throwing untested builds to users
(13:03:25) mattock: so #2: do we always want to support two releases 
("oldstable" and "stable") at the same time
(13:03:30) ordex: scratch that from the log
(13:03:31) ordex: :D
(13:03:33) cron2: orex: *roll eyes*
(13:03:35) plaisthos: cron2: could do but it is not really a good image to 
start with nowadays since there is too much other stuff on the box
(13:04:02) ordex: not untested, but not as tested as I'd like them to be
(13:04:23) cron2: plaisthos: mmmh.  I wonder how to make a nice OSX test VM...  
(without running vmware on $wife's mac mini)
(13:04:44) cron2: mattock: easy answer - "no", only for a limited time
(13:04:46) plaisthos: cron2: what is your virtualisation tech?
(13:04:48) cron2: as we did with 2.2 + 2.3
(13:04:53) syzzer: re #2: let's create a wiki page where we announce what we 
support and until when
(13:05:04) cron2: plaisthos: ESX, but I need to make an exception for OSX :)
(13:05:08) syzzer: dates are easier than "4 dot-releases"
(13:05:13) mattock: cron2: at what point did we stop supporting 2.2? what 2.3.x 
release was that?
(13:05:30) mattock: I'm just wondering because we're at 2.3.18 now :P
(13:05:30) plaisthos: cron2: you can patch esx to allow os x but that is 
probably not your pick of poison
(13:05:39) mattock: and 2.4.4
(13:05:40) cron2: mattock: it was sort of "we never officially stopped 
supporting it, we just didn't feel the need to do more releases"
(13:05:43) plaisthos: cron2: I can also give you a shell on my machine
(13:05:54) cron2: like, if there are no features and no bug fixes, why do a 
(13:06:03) cron2: plaisthos: that would be nice
(13:06:06) plaisthos: cron2: if you have a *Intel* KVM machine os x is 
relatively to setup
(13:06:22) dazo: ordex: mattock: can we look into getting a public osx image 
accessible for the community? 
(13:06:45) ordex: dazo: mhhh accessible in what sense ?
(13:06:57) dazo: like a buildslave 
(13:07:11) ordex: ah like the one we use for jenkins
(13:07:14) ordex: well, it's just a vm
(13:07:15) dazo: yeah
(13:07:19) ordex: we run it on ESXI
(13:07:20) syzzer: dazo: travis does osx builds (but not tests)
(13:07:20) dazo: something which cron2 can poke at :-P
(13:07:42) syzzer: but, focus, oldstable support
(13:07:44) cron2: ordex: OSX on ESXI?  How?
(13:07:51) dazo: syzzer: right, I think it's the t_client.sh which is relevant 
in this round :)
(13:07:53) cron2: syzzer: so boring
(13:07:57) syzzer: :p
(13:08:08) ordex: cron2: dunno. as far as I know that's the only VM tech 
supported by apple
(13:08:12) ordex: it's a VMWare thing
(13:08:17) ordex: but I don't know much more than that
(13:08:19) ordex: I did not set it up
(13:08:22) cron2: orex: actually it's *not* supported
(13:08:33) cron2: ESX refuses to boot OSX unless you modify *ESX*
(13:08:47) cron2: now, vmware *on apple hardware* (or maybe ESX *on apple 
hardware*) is fully supported...
(13:08:59) mattock: syzzer: I don't see focus
(13:09:00) mattock: :P
(13:09:05) mattock: except on MacOS X
(13:09:09) syzzer: mattock: no, I tried...
(13:09:09) dazo: all I know is that we said: "Andrew, we need an osx jenkins 
slave, can you fix it?" ... and got "here it is!"
(13:09:11) ordex: cron2: no clue honestly. I should check where we run esxi
(13:09:24) cron2: wrt oldstable: my gut feeling is "at some point, we'll see no 
security-relevant updates anymore, so there is no real *need* to do releases 
(13:09:38) mattock: so a follow-up question
(13:09:40) dazo: compare it to v2.2
(13:10:00) mattock: could we just decide that at some point we move to 
"source-only" releases for "oldstable"
(13:10:12) dazo: But we've slowed down v2.3 stuff to basically a minimum 
nowdays, haven't we?
(13:10:15) cron2: dazo: that's what I did :-) - we never made a conscious 
decision to "this is now unsupported", we just stopped making releases (and a 
year later, decided "source-only is good enough")
(13:10:24) cron2: (that comment was about 2.2)
(13:10:32) dazo: yeah :)
(13:10:45) mattock: it seems that we're getting security fixes quite frequently 
nowadays, unlike during 2.2/2.3 phase
(13:10:46) cron2: well, 2.3 has been a bit unusual this year because people 
kept finding nasty security relevant bugs
(13:10:51) mattock: yeah
(13:10:51) cron2: this
(13:11:22) dazo: yeah, we've not had any year ever before with this amount of 
CVEs flowing in ... so this have been a spectacular year
(13:11:50) cron2: so, anyway, this is my suggestion - unless something comes up 
that "we think we need a release", just put it into maintenance mode and that's 
(13:11:50) dazo: and in that context, what we've done with v2.3 have been 
relevant ... as there are still users depending on that for various reasons
(13:11:58) dazo: cron2++
(13:11:58) syzzer: so, can we settle on something like "once a stable becomes 
oldstable, it will receive at least 6 months of full releases and 18 months of 
source releases" ?
(13:12:22) plaisthos: for critical bugs/security fixes
(13:12:24) plaisthos: only
(13:12:24) ***cron2 doesn't feel good about making strict timelines when we 
have no idea how 2.4/2.5 will look like
(13:12:26) mattock: source-only would primarily affect Windows users and our 
apt repo users (who would have to move to "stable" or rebuild "oldstable" with 
the fixes)
(13:12:51) dazo: cron2++ (again)
(13:13:01) plaisthos: source only means "not for general use" anyway
(13:13:10) cron2: but yeah, if we want to make a statement, I could live with 
what syzzer suggested - "that's what we already did anyway" :)
(13:13:25) dazo: if those time lines are relative to the latest stable release 
(like a future v2.5), these time lines are reasonable
(13:13:43) mattock: plaisthos: agreed, except that package maintainers would 
not feel any difference
(13:14:02) mattock: dazo: that was my idea
(13:14:19) dazo: due to our not too frequent major releases, I think it should 
be 12/24 months ... but that's just my opinion
(13:14:20) mattock: so "after 2.5.0 we will provide <n> months of 2.4.x 
(13:14:25) syzzer: it's why I say "at least" in the statement; we promise to do 
that and might decide to do more.  At least it gives users an idea about the 
timelines for their upgrade paths
(13:14:32) plaisthos: most package mainter will also not stick to old versions 
that long
(13:14:40) dazo: ahh, good point syzzer 
(13:14:42) cron2: syzzer: yeah, I think that is workable
(13:14:48) cron2: (I was a bit confused initially)
(13:15:07) plaisthos: source only is like "we patch it for you so you don't 
screw up when trying to backport the patch yourself"
(13:15:16) dazo: yeah
(13:15:29) dazo: but source-only .... do we provide tarballs (but no binaries) 
... or git only?
(13:15:44) mattock: dazo: good question
(13:15:48) ordex: mah github provides tarball as well..we can stick to git
(13:16:00) cron2: if we do a *release*, with a number, a git tag, etc., we 
should provide tarballs
(13:16:00) mattock: I tend to agree
(13:16:15) dazo: yeah, I'm leaning towards what cron2 says
(13:16:23) mattock: I'm not opposed to tarballs because releasing those is 
(13:16:30) syzzer: cron2++, running 'make dist' is an acceptible amount of 
work, right/
(13:16:33) ordex: but github provides the tarballs for each release too, no? 
without the need for us to do anything other than signing commits and tags
(13:16:46) ordex: unless our tarball provides something more
(13:16:51) syzzer: (at leat for -NL, most of the release work is in the distro 
repos and windows installers)
(13:16:52) plaisthos: ordex: it does
(13:16:57) dazo: ordex: signed tarballs ;-)
(13:16:58) plaisthos: ordex: e.g. a configure script
(13:17:02) mattock: syzzer: same at my end
(13:17:09) ordex: oky
(13:17:43) mattock: 2.3 has quite a bit of "legacy" stuff in it so moving it to 
"source-only" mode would be nice
(13:17:45) dazo: but yeah, 'make dist' is bootstrapped tarballs
(13:17:50) syzzer: ordex: 'make dist' generates tne configure script, so users 
don't need autoconf to build the release
(13:17:55) mattock: old openvpnserv.exe, WinXP (i.e. tap-windows), etc.
(13:17:59) ordex: oky
(13:18:43) ordex: so 'make dist' sounds like a good compromise ?
(13:18:46) dazo: Shall we agree that the next v2.3 release (whenever that 
happens) will be the very last binary release?
(13:18:53) mattock: I sure can :P
(13:18:59) ordex: :D
(13:19:07) syzzer: dazo: that was what I was about to say
(13:19:12) dazo: and we just do tarball releases for 2.3 following that 
(13:19:12) ordex: sounds good
(13:19:17) ordex: let's just announce that clearly
(13:19:28) dazo: yeah
(13:19:40) cron2: I would tie that to "... unless a major security issue pops 
up", but I think we've had our share of that... source code reviews, fuzzer, ...
(13:20:20) ordex: yeah, but i don't think we need to write that in the 
announcement (?). if that happens, we just release the binary and say it was 
(13:20:34) ordex: exceptionally buggy :P
(13:20:35) mattock: one of the problems with providing (windows) binaries is 
that we also need to keep dependencies (e.g. openssl) updated
(13:20:36) dazo: cron2: hence "after the next release" ... at some point we 
need to stop caring that much .... v2.4 have been out for about 11 months or so 
(13:20:56) mattock: so if we move 2.3 to source-only, we no longer have to 
worry about OpenSSL vulnarabilities in 2.3 installers
(13:21:12) dazo: oh, true
(13:21:20) dazo: the bundled dependency hell
(13:21:23) mattock: yeah
(13:21:42) mattock: oh, and NSIS also
(13:22:47) ordex: ok. so one more and then source (except excptions)?
(13:22:57) ordex: $somebody will write an email?
(13:22:57) mattock: yes
(13:22:58) dazo: regarding NSIS ... do we have a plan to move towards MSI 
installers?  any planned eta on that?
(13:23:06) mattock: dazo: we have a plan, but no resources
(13:23:23) mattock: I think I would have to at least bootstrap that project, 
but as you know, "stuff keeps coming up"
(13:23:34) mattock: so prioritization, prioritization...
(13:23:43) dazo: yeah, and we probably could need more community help too
(13:23:51) mattock: if we get a reasonable MSI installer out we can probably 
expect contributions
(13:24:06) mattock: or rather, quite likely
(13:24:24) mattock: chipitsine would help, and the chocolatey package 
maintainer actually brought the MSI thing up in the first place
(13:24:28) mattock: before the NSIS security issue
(13:25:07) mattock: it will probably be a couple of days of work to create an 
installer that works
(13:25:46) mattock: do we want to define a "end of life" policy for oldstable 
(13:26:03) dazo: I'm all for tossing that challenge to someone who's not so 
heavily involved ... and we'll see what happens and review that
(13:26:25) mattock: dazo: we can try definitely
(13:28:01) mattock: I can start probing for potential MSI guys
(13:28:08) dazo: I can start a wiki page with a proposal for the life cycle 
policy ... and then we can discuss that next meeting
(13:28:17) mattock: sounds good
(13:28:28) mattock: maybe send email to openvpn-devel once the initial page is 
(13:28:30) syzzer: dazo: just made a start here: 
(13:28:31) vpnHelper: Title: SupportedVersions – OpenVPN Community (at 
(13:29:00) syzzer: very course, tried to write down what I think is our current 
support status
(13:29:02) dazo: syzzer: thx!  I can work a bit more on that, this is a good 
starting point
(13:30:01) syzzer: MSI is supposed to be very easy (according to $colleague)
(13:30:04) dazo: so we're hitting the 1 hour mark now :)
(13:30:18) syzzer: and because I'll need to get -NL over too, I'm willing to 
help out a bit there too
(13:30:23) dazo: cool!
(13:30:25) mattock: syzzer: he's probably right, especially if one knows MSI 
beforehand :P
(13:30:38) mattock: syzzer: \o/
(13:30:42) syzzer: anyway, time for lunch?
(13:30:47) mattock: sounds good to me
(13:30:50) dazo: +1
(13:31:07) mattock: I will write the summary post-lunch
(13:31:08) syzzer: perfect, ttyl then!
(13:31:13) mattock: bye!
(13:31:14) ***syzzer hungy :p
(13:31:16) ordex: :D
(13:31:24) ***ordex prepares dinner
(13:31:33) ordex: bye!
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to