Commit 9ee954

2026-09-09 11:59:02 novaflash: -/-
Meetings/2026/2026-09-02.md ..
@@ 16,35 16,4 @@
This would allow for a client to for example select the best available server based on test results.
The RFC for this was merged to OpenVPN protocol specification documentation.
The patch series can be found here: https://gerrit.openvpn.net/q/topic:%22oob-server-probe%22
- ralf_lici reviewed the RFC earlier, and said he would be willing to take a look at the patch series next.
-
- # Backlog
-
- - **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 we have some idea of what to do. Will check with designer if he can do it for us.
-
- * **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.
-
-
- * **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.
+ ralf_lici reviewed the RFC earlier, and said he would be willing to take a look at the patch series next.
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