Commit 08dcb2
2026-09-30 12:02:24 novaflash: -/-| /dev/null .. Meetings/2026/2026-09-30.md | |
| @@ 0,0 1,39 @@ | |
| + | # Basic info |
| + | |
| + | * Time: Wednesday 30 September 2026 at 14:00 CEST (12:00 UTC) |
| + | * Place: #openvpn-meeting channel on !LiberaChat IRC network |
| + | |
| + | # Topics |
| + | |
| + | * **Updated: 2.7.x release** |
| + | A few more security fixes are coming in 2.7.8, and this is planned for October 1st. |
| + | |
| + | * **Updated: 2.6.x release** |
| + | 2.6.23 was released last week, it contains a number of small security fixes and bug fixes. |
| + | |
| + | - **Updated: 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. |
| + | For the t-shirt, novaflash will put something together and throw it in community signal chat tomorrow. |
| + | |
| + | |
| + | # 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. |
| + | This would allow for a client to for example select the best available server based on test results. |
| + | This is currently under review: https://gerrit.openvpn.net/q/topic:%22oob-server-probe%22 |
| + | The design document is here: https://github.com/lstipakov/openvpn/blob/server-probe-design/design-server-probe.md |
| + | |
| + | - **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. |