Blame
| 6f02e7 | Samuli Seppänen | 2025-01-29 06:40:08 | 1 | # Development/testing issues |
| 2 | ||||
| 3 | ## [Beaker test framework](https://fedorahosted.org/beaker) |
|||
| 4 | ||||
| 5 | Should we start configuring a dedicated testing framework for OpenVPN? This idea will be presented by _mattock_. |
|||
| 6 | ||||
| 7 | - **Rationale** |
|||
| 8 | - Would allow testing that OpenVPN works on a large number of predefined platforms and configurations. |
|||
| 9 | - Replaces part of the manual testing effort by testing the external behavior of the application automatically. |
|||
| 10 | - Would allow spotting bugs early. |
|||
| 11 | ||||
| 12 | - **Implementation ideas** |
|||
| 13 | - Beaker could perhaps be made to simulate poor connections for testing purposes. If not, there are plenty of tools and services available for this purpose (see full chatlog). |
|||
| 14 | ||||
| 15 | - **Limitations** |
|||
| 16 | - Only tests for external behavior of the application. |
|||
| 17 | - Does not replace human testing for those classes of problems which are difficult/impossible to test programmatically. |
|||
| 18 | ||||
| 19 | ## Continuous integration server |
|||
| 20 | ||||
| 21 | Should we build a continuous integration (CI) / automated release management server? This idea will be presented by _mattock_. |
|||
| 22 | ||||
| 23 | - **Rationale** |
|||
| 24 | - Would allow spotting build problems early on by building "allmerged" and reporting developers of build problems. |
|||
| 25 | - Would reduce developer frustration. |
|||
| 26 | - Would allow automated packaging of OpenVPN-testing for various platforms and publishing those on a web server. |
|||
| 27 | - The above would translate to increased use of OpenVPN-testing, leading to earlier bug reports and would thus make the release process (new code -> acceptance to testing -> acceptance to stable -> release) faster. |
|||
| 28 | - Could also allow centralized automated searching of code problems. |
|||
| 29 | ||||
| 30 | - **Implementation ideas** |
|||
| 31 | - Developers could be notified of problems using email. |
|||
| 32 | - The OpenVPN project has a license to [Coverity](http://www.coverity.com/) service. As this service has an API, Coverity code analysis could be integrated into the CI server. |
|||
| 33 | ||||
| 34 | - **Limitations** |
|||
| 35 | - Does not replace human testing. |
|||
| 36 | - Only tests the build process (and possibly code problems). |
|||
| 37 | ||||
| 38 | ## Developer bounties |
|||
| 39 | ||||
| 40 | Should we have a bounty system for writing missing features? Similar systems are in use by several other projects, e.g. freeswitch, pfSense, and Funambol. This idea will be presented by _ecrist_. |
|||
| 41 | ||||
| 42 | - **Rationale** |
|||
| 43 | - Would allow users to prioritize feature additions through compensation. |
|||
| 44 | - Would help achieve greater interest of developers in users' requests and needs. |
|||
| 45 | ||||
| 46 | - **Implementation ideas** |
|||
| 47 | - Bounty funds would be set up and maintained by a non-developer (ecrist?) and held. This assures payment upon completion and assures the feature is completed before bounty is paid. |
|||
| 48 | - Multiple users could fund a bounty for intensive feature additions which may warrant higher payouts. |
|||
| 49 | - Developers set up accounts and 'claim' tasks. |
|||
| 50 | - After a specific timeout, a task becomes available to another user, unless progress can be shown. |
|||
| 51 | - Payment could be divided into multiple phases to motivate developers to maintain the code they've written. For example: |
|||
| 52 | - 50% payout for a commit to the main tree. |
|||
| 53 | - 25% upon release in production (provided bugs are fixed/etc). |
|||
| 54 | - 25% 6 months after release (provided bugs are fixed/etc). |
|||
| 55 | - The above would also guarantee the quality of the code. |
|||
| 56 | - Handling monetary transactions: |
|||
| 57 | - Could be handled through an external foundation/organization (e.g., [SPI](http://www.spi-inc.org/projects)). |
|||
| 58 | - We could establish our own foundation for this purpose. |
|||
| 59 | - Licensing and copyright: |
|||
| 60 | - Developer would have to use the BSD license for the bounty features. |
|||
| 61 | - This would allow the project to relicense the code under GPLv2 (while mentioning the original author). |
|||
| 62 | - This would allow both developer (payee) and payer to use the code any way they wish. |