[Openvpn-devel] Splitting the ACK/NACK system into two?

[Samuli S. <sa...@op...>]

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>