OpenVPN 2.3-alpha2 release


Alon hopes to get the following patches included in 2.3-alpha2:

ACK and merge, or NACK.

@ALON: The bool branch is the one for discussion, it is the last issue we have in building openvpn in various of configurations without warnings/errors. The question is what course should we take? stdbool (unlike its name, is far from being standard) or just rename the bool to obool to reduce risk (we actually do not change anything), achieve compiler portability and achieve C++ compatibility. I recommend taking the rename approach.

Git repo layout

Alon's refactoring/buildsystem patches split the project into two separate projects (taken from here):

  • openvpn - standard open source project, autotool based build system, like any other project its build system only builds it-self.
  • openvpn-build - a separate project to build openvpn in various of configurations. This project is divided into the following components:
    • generic - a generic build using cross compiler, included the complete dependencies.
    • msvc - a MSVC build using Microsoft specific msbuild system, I hope this will die eventually.
    • windows-nsis - the windows installer generator, it uses the generic component to build using mingw cross compiler, then package the output using nsis.

The openvpn and openvpn-build subprojects can be developed fairly independently. Do we need/want to host both subprojects in the same place?

@ALON: We have few more new repositories: tap-windows, easy-rsa. Is there any reason NOT to host them at the same place? I just cannot think of any...

Suggested changes to development processes

Subsystems vs. features

These has been critique on our current focus on features (e.g. PolarSSL, IPv6) instead of subsystems (e.g. crypto, routing, buildsystem). It was claimed that this may in the long run cause a crisis for the project by making the code more complex than it has to be. This raises a few questions:

  • Does the subsystem approach make sense to everyone on a theoretical level?
  • Is the subsystem approach doable in practice, given our current developer base?
    • Would current, active developers be interested in taking responsibility over a subsystem?
    • If so, how do we handle practical issues such as:
      • Do we want to allow direct commit access to official repositories for the subsystem maintainers?
      • Do we want to use subsystem-specific trees (e.g. at GitHub) from which code is pulled into the official OpenVPN Git repository?
      • Do we want to change the mandatory ACK/NACK process for the less-critical subsystems? For example, openvpn-build subsystem is not critical from security perspective.

Git repos: GitHub <->

There have also been suggestions to move the Git repos to GitHub:

  • There is anecdotal evidence that GitHub promotes collaboration[1] greatly compared to the traditional mailing list approach[2]
  • What benefits does provide?
  • What benefits does GitHub provide?

[1] I.e. increases the number of patches/pull requests sent to the project

[2] This can probably be accounted by fewer barriers to entry, for example not requiring subscribing to openvpn-devel list prior to sending in a patch. How great the impact is probably depends on the project and is hard to estimate before trying it out.

@ALON: Some discussion was here. GitHub supports many features that lacks, RSS of changesets, review and comment, the entire merge process and more. Mainly it supports finer grain privileges for multiple repositories. I don't think there is one single advantage in keeping using the, especially if the OpenVPN project is only using git feature of

ACK -> maintenance responsibility?

Another suggestion made Alon is that giving an ACK would mean taking responsibility of the ACKed code, should the original developer disappear somewhere. This would have some benefits:

  • Only code that was really important would get in
  • The code that got included be the responsibility of at least two people, the author and the ACKer; this should (at least in theory) result in fairly well-maintained code with fewer "orphaned" parts

This approach has a few potential drawbacks:

  • Less potentially useful code gets in
  • Moves away responsibility from the original developer

@ALON: If useful code gets in and there is no active long term maintainer for this "useful" feature, what can we say about the quality of the implementation or user support?

@ALON: Original developer should be defined properly, by my definition James is an original developer of OpenVPN, while he did not write 100% of the code... A patch contributer is far from being "original developer", as there is no real relationship between the contributer and the project, how did the current process defined "responsibility" of this contributer? Let's say contributer succeeded in getting his code into the tree by someone ACK, then after a release, there were issues with his changeset. Is he is obligated to fix his code? how can you enforce this? In my view whoever ACKed is accountable for this code for long term, this does not reduce the cooperation with contributer, just define clearly who is accountable for changes accepted to the code base.

OpenVPN 2.4

Should OpenVPN 2.4 release cycle focus on cleaning up the codebase, for example integrate new features (e.g. IPv6) better into the old codebase?

buildbot testing

get automated connectivity tests with IPv4 and IPv6 going - this would have caught the Linux IPv6 regression right away, not later when it bit dazo

Last modified 10 years ago Last modified on 04/26/12 18:29:33