Hi all, Lately I've been thinking of ways to improve our ACK/NACK system so that patches could get merged _or_ rejected faster. There have some cases where no clear resolution has been reached, one example being the floating-tls patch[1]. The way I see it, whether a patch should be merged into OpenVPN depends on two factors:
a) Does it make sense (feature-vise) to include the patch in OpenVPN? b) Is the patch of good quality / does it follow our coding conventions? Of these a) should be the primary consideration, after which b) can be looked into. In some cases determining a) is trivial, e.g. if the patch fixes a bug. Similarly, determining b) should be easy most of the time. Only patches which add, modify or remove features may require in-depth discussion on b). Although all of this is obvious, I've noted that very few non-developers have participated in the ACK/NACK system, even they would be perfectly capable of handling a). A good example is the DHCP filtering patch[2]. Therefore, I propose the following formal modification to the ACK/NACK system: - anybody can give a "Feature ACK/NACK" (a) for any given patch; or, in other words saying "this patch is worth/not worth including" - once (a) is given, a developer can give "Code ACK/NACK" (b), which will result in merging the patch or in request to modify the patch To avoid adding extra layer of bureaucracy both ACKs (a+b) could be given by the same person. I believe this approach would give us several benefits: - allow more people to participate in the ACK/NACK work - reduce workload of the developers (due to ^^^) - help focus on a) before b) - allow quicker rejection of "this does not make sense" type patches - allow sharing responsibility in giving an ACK (e.g. if developer can't give a "Feature ACK", but can still give a "Code ACK") Any thoughts? -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock [1] <http://thread.gmane.org/gmane.network.openvpn.devel/4213> <http://thread.gmane.org/gmane.network.openvpn.devel/4378> <http://article.gmane.org/gmane.network.openvpn.devel/4221> [2] <https://forums.openvpn.net/topic7479.html>
