| | 1 | = OpenVPN 2.3-alpha2 release = |
| | 2 | |
| | 3 | == Patches == |
| | 4 | |
| | 5 | Alon hopes to get the following patches included in 2.3-alpha2: |
| | 6 | |
| | 7 | * https://github.com/alonbl/openvpn/compare/master...cxx |
| | 8 | * https://github.com/alonbl/openvpn/compare/master...warnings |
| | 9 | * https://github.com/alonbl/openvpn/compare/master...unicode |
| | 10 | * https://github.com/alonbl/openvpn/compare/master...git-attributes |
| | 11 | * https://github.com/alonbl/openvpn/compare/master...bool |
| | 12 | |
| | 13 | ACK and merge, or NACK. |
| | 14 | |
| | 15 | == Git repo layout == |
| | 16 | |
| | 17 | 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]): |
| | 18 | |
| | 19 | * ''openvpn'' - standard open source project, autotool based build system, like any other project its build system only builds it-self. |
| | 20 | * ''openvpn-build'' - a separate project to build openvpn in various of configurations. This project is divided into the following components: |
| | 21 | * ''generic'' - a generic build using cross compiler, included the complete dependencies. |
| | 22 | * ''msvc'' - a MSVC build using Microsoft specific msbuild system, I hope this will die eventually. |
| | 23 | * ''windows-nsis'' - the windows installer generator, it uses the generic component to build using mingw cross compiler, then package the output using nsis. |
| | 24 | |
| | 25 | The ''openvpn'' and ''openvpn-build'' subprojects can be developed fairly independently. Do we need/want to host both subprojects in the same place? |
| | 26 | |
| | 27 | = Suggested changes to development processes = |
| | 28 | |
| | 29 | == Subsystems vs. features == |
| | 30 | |
| | 31 | 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: |
| | 32 | |
| | 33 | * Does the subsystem approach make sense to everyone on a theoretical level? |
| | 34 | * Is the subsystem approach doable in practice, given our current developer base? |
| | 35 | * Would current, active developers be interested in taking responsibility over a subsystem? |
| | 36 | * If so, how do we handle practical issues such as: |
| | 37 | * Do we want to allow direct commit access to official repositories for the subsystem maintainers? |
| | 38 | * Do we want to use subsystem-specific trees (e.g. at GitHub) from which code is pulled into the official OpenVPN Git repository? |
| | 39 | * 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. |
| | 40 | |
| | 41 | == Git repos: !GitHub <-> SF.net == |
| | 42 | |
| | 43 | There have also been suggestions to move the Git repos to GitHub: |
| | 44 | |
| | 45 | * There is anecdotal evidence that GitHub promotes collaboration[1] greatly compared to the traditional mailing list approach[2] |
| | 46 | * What benefits does SF.net provide? |
| | 47 | * What benefits does GitHub provide? |
| | 48 | |
| | 49 | [1] I.e. increases the number of patches/pull requests sent to the project |
| | 50 | [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. |
| | 51 | |
| | 52 | == ACK -> maintenance responsibility? == |
| | 53 | |
| | 54 | 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: |
| | 55 | |
| | 56 | * Only code that was really important would get in |
| | 57 | * 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 |
| | 58 | |
| | 59 | This approach has a few potential drawbacks: |
| | 60 | |
| | 61 | * Less potentially useful code gets in |
| | 62 | * Moves away responsibility from the original developer |
| | 63 | |
| | 64 | == OpenVPN 2.4 == |
| | 65 | |
| | 66 | 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? |
| | 67 | |
| | 68 | |
| | 69 | |
