Stefan Monnier ha scritto: >> 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 > Very good points. The first challenge is reviewing patches. I guess many problems can be spotted with a quick look on the patch. These problems should communicated so that they can be fixed. And if the patch is included, then we should communicate that, too. Otherwise the committer might think his/her patch was rejected.
Now, if we want to maintain stability, we need some way to test the patches. Automated tests could be used in many cases but building the test cases takes time. In addition I don't think automated tests catch nearly all problems, so manual testing is required. I'm not a specialist in VCS systems but I guess a distributed VCS could help in this. What are your thoughts on the testing procedures/tools? Fedora's Beaker suite was mentioned earlier and it sounds interesting. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc
