Home A - Z
Page Index

An Otter Wiki

Commit 504fbe

2026-08-26 12:03:41 novaflash: -/-
Meetings/2026/2026-08-19.md ..
@@ 17,31 17,4 @@
* **Updated: Amount of open changes in the queue**
OpenVPN Inc. and cron2 reached a deal where he gets paid part-time to work on OpenVPN2 code reviews/merges.
We encouraged razvanc and chugly from the company to get involved in the community as well to speed up reviews.
- lev also promised he would spend some more time on reviewing, after his vacation.
-
-
- # Backlog
-
- - **test latency and MTU in openvpn**
- A new feature is proposed for adding to master; ability to do latency and MTU tests in the OpenVPN protocol.
- Idea is to allow to do a 'best server selection' type of logic, in case there are multiple servers available to connect to.
- RFC PR is at https://github.com/OpenVPN/openvpn-rfc/pull/30 and an early initial implementation is available from lev.
- What's needed is a community member's review and ralf_lici did so and provided some comments.
-
- * **publish also on codeberg**
- Suggestion was made by cron2 to also publish openvpn2 on codeberg. OpenVPN3 Linux is already there at this time.
- It would not replace github but just serve as another place to publish the code.
- No clear decision made as yet. Concerns raised about new avenues of opening tickets/PRs.
-
- - **2.7 security audit**
- The security audit was completed for 2.7.0 and results are available internally.
- We are working to publish this in an official blog post. ordex and novaflash are driving this in OpenVPN Inc. internally.
-
- * **Coordinating big changes**
- A related discussion is how to handle big changesets (e.g. currently the multipeer changes from plaisthos and the
- oob changes from lev). There was some unhappiness that these changesets are dropped without sufficient context and
- that makes it hard to keep track of all the developments. One advise is that developers that want to have big (or many)
- changes merged are encouraged to write a mail to the mailing list to provide a "cover letter" for the patch set and
- a convenient place to discuss the overall direction without getting bogged down in the discussion of individual changes.
- We have lost this practice since not generally using mail-based patchsets anymore. That can be also a good opportunity
- to point out dicussions happening in PRs for the RFC document.
+ lev also promised he would spend some more time on reviewing, after his vacation.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9