Commit 3ac308

2026-08-05 12:01:10 novaflash: -/-
/dev/null .. Meetings/2026/2026-08-05.md
@@ 0,0 1,42 @@
+ # Basic info
+
+ * Time: Wednesday 5 August 2026 at 14:00 CEST (12:00 UTC)
+ * Place: #openvpn-meeting channel on !LiberaChat IRC network
+
+ # Topics
+
+ * **Updated: 2.7.6 release**
+ We want to do another release for security fixes. Some of them didn't seem worth keeping embargo on, so those are reviewed on Gerrit.
+ Currently we are planning for a release next week around August 5th.
+ There will be a 2.6.22 release as well.
+
+ # 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.
+
+ - **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.
+
+ * **Amount of open changes in the queue**
+ Some discussion about the number of open patches (e.g. about 120 open changes in Gerrit). We definitely need to
+ look into our processes again and how to spread all that work reviewing, testing, and integrating. Likely also a
+ topic for the 2026 Community Meetup in Paderborn. djpig is working on better documenting the current processes,
+ see e.g. [1776: Start a new document CODE_CHECKLIST](https://gerrit.openvpn.net/c/openvpn/+/1776) in Gerrit.
+
+ * **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.
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