= 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 [http://thread.gmane.org/gmane.network.openvpn.devel/6280/focus=6297 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 [http://article.gmane.org/gmane.network.openvpn.devel/6288 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?