OpenVPN 2.3-alpha2 release

Patches

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

• ​https://github.com/alonbl/openvpn/compare/master...cxx
• ​https://github.com/alonbl/openvpn/compare/master...warnings
• ​https://github.com/alonbl/openvpn/compare/master...unicode
• ​https://github.com/alonbl/openvpn/compare/master...git-attributes
• ​https://github.com/alonbl/openvpn/compare/master...bool

ACK and merge, or NACK.

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?

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 <-> SF.net

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 SF.net 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.

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

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?