> One the one hand people expect OpenVPN to be rock-solid in both
> stability and security. In order to maintain this standard of quality,
> there needs to be a rigorous process of patch vetting. On the other
> hand, as an open source project, OpenVPN needs to be transparent and
> open to contributions from the community.
That misses the main issue: you can reject most patches on some
stability ground, but then as a contributor I'd like to know how to
improve my patch to make it acceptable.
E.g. my "fqdn route with fqdn's that map to multiple IPs" patch (which
I consider to be a bug-fix rather than a feature addition) has been
somewhat discussed but only w.r.t the functionality, not the actual
code, so I have no idea what I need to do in order to have it
be accepted. This is frustrating.
This said, as a maintainer of a Free Software package, I am quite aware
that giving responding to all contributions (let alone giving good
feedback) can be challenging.
Stefan
