> Here's a summary of yesterday's meeting. This and earlier meeting > summaries are linked to from here: > > http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings > >
Oops, and the actual summary here :). -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
COMMUNITY MEETING Place: #openvpn-discussion on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday, 4th January 2010 Time: 19:00 UTC Full log available here: http://secure-computing.net/logs/%23%23openvpn-discussion.log Next meeting on Thu 11th Feb 2010. Same place, same time. SUMMARY Decided to follow David Sommerseth's plans regarding the development process, described in detail in this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=20100204190039.GU857%40greenie.muc.de&forum_name=openvpn-devel Some of the basic ideas are incorporated into this process (swimlane) diagram: http://users.utu.fi/sjsepp/openvpn/getting_code_to_openvpn.png Decided to host David's Git trees in SF.net under the "openvpn" project. James will take care of granting the necessary permissions for David to do that. Decided to start writing basic developer documentation (e.g. coding conventions, the rules outline in David's email...). This content will be hosted in the Secure Computing Wiki (http://www.secure-computing.net/wiki/index.php/OpenVPN) until the OpenVPN Community site Wiki is up. Decided to start testing the new development process by integrating the existing IPv6 patchsets to David's Git tree. Discussed compile-time enablement/disablement of features (#ifdef'd segments in code): - usage of #ifdefs is necessary to avoid bloat, which hurts OpenVPN's usage especially in embedded systems - heavy use of #ifdef's can make the code hard to understand - use of #ifdef's can cause problems when a feature requires extra arguments to function, which leads to more code to maintain Agreed that code near the core itself should be #ifdef'd sparingly, whereas code at the periphery (e.g. new features) should be #ifdef'd. Agreed that the basic development process should go like this: - At least 2 developers have to accept each patch (ACK) before it gets to testing tree(s) to weed out obviously bad stuff - After initial testing the somewhat stable patchces are merged to the s.c. "stable" SVN tree maintained by James - Each release goes through a "feature freeze" where no new functionality is added so most bugs can be weeded out Agreed that there is a need to organize the people doing testing because the absense of bug reports (in, say 2 weeks) does not prove that a piece of new code does not have serious problems. In a nutshell, lack of bug reports tells us that a) there are no problems with the (new) code b) nobody is using the (piece of the) code which has the problem Agreed that there should be active testers who inform the developers if new code works for them - not just report problems if they encounter them. This helps detecting b), above. Agreed that developer versions of the application should visibly display them as such, e.g. by printing "This is a devel branch, report your bugs [here] or we'll hunt you down" to STDERR. --- Discussed forums/mailinglist and packaging topics after the hard-core developer portion was over... Decided that Samuli will take a look at available OSS forum applications before next meeting. Eric will take a look at commercial alternatives. Decided to use Debian Experimental repository to redistribute OpenVPN packages built from David's "testing" tree (allmerged?) to Debian users. Alberto volunteered to do the building and uploading to the Debian experimental (~ once per week). Discussed the need for building "testing" packages each day and distributing them using our own (Debian/Fedora/whatever) repositories. The official Debian repositories require manual work, so fully automated system is not possible without a custom apt repo. Eric volunteered to provide FreeBSD binaries (from "testing"?) on a weekly basis.
