Commit 4bd5cb

2026-08-19 11:59:32 novaflash: -/-
Meetings/2026/2026-08-12.md ..
@@ 22,29 22,4 @@
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.
-
- # Backlog
-
- * **New: 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.
-
- - **community meetup 2026**
- Coordination is currently taking place here: https://community.openvpn.net/Meetups/2026-Paderborn
- The date is around 17 and 18 October, location in Paderborn, Germany.
- ordex has volunteered to update and polish the page, fill in some further details.
-
- - **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.
+ What's needed is a community member's review and ralf_lici did so and provided some comments.
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