On Wed, Nov 02, 2016 at 10:12:59AM +0200, Samuli Seppänen wrote: > Il 02/11/2016 00:52, Arne Schwabe ha scritto: > > On 01.11.2016 23:47, David Sommerseth wrote: > >> > >> I'm splitting of the originating thread to a new one, to refocus the > >> discussion. > >> > >> On 01/11/16 15:56, Samuli Seppänen wrote: > >>> Il 01/11/2016 16:05, David Sommerseth ha scritto: > >>>> [...snip...] > >>>> > >>>>>> I still think the timeline "end of 2016" should be doable - > >>>>>> there's some reasoning to meet that: it will make the next > >>>>>> Debian release. > >>>>> > >>>>> If Debian 9 is frozen by the end of the year, then that is a > >>>>> good goal. > >>>> > >>>> Yes, that is a good goal. And we *must* reach that one, IMO. > >>>> > >> > >>> Agreed. I don't see any major blockers there. We just have to push > >>> out 2.4 beta/rc releases out in quick succession to reach that > >>> goal. > >> > >> Samuli and I have had a little side-channel dialogue in regards to the > >> release schedule today. > >> > >> According to this [1] overview, Debian 9 (Stretch) have the soft-freeze > >> deadline January 5, 2017. That is the date we must have released the > >> final 2.4 to be in the Debian game. > >> > >> [1] <https://wiki.debian.org/DebianStretch> > >> > >> That doesn't sound too bad. But it is a very short deadline - 9 weeks! > >> Including a Christmas holiday (roughly 2 weeks), where we can't expect > >> too much to happen. And we should have at least one week slack to catch > >> critical emergencies before the final release. Which means we have 6 > >> weeks to go from alpha2 to 2.4.0. > >> > >> My opinion is that we do not have time for the complete alpha/beta/rc > >> cycles. We need to skip either beta or RC, unless we decide to release > >> the first beta this week. > >> > >> I _/*SUGGEST*/_ a schedule like this: > >> > >> > >> * November 1st - "TODAY" (for roughly 20 more minutes) > >> 2.4_alpha2 has been out for almost 2 weeks (13 days, if I'm not > >> mistaken). We have 11 patches queued up in master since that release. > >> > >> > >> * November 7th > >> Developers meeting. Agree on what goes into the beta/rc release > >> and not. Also agree on if we simplify the release cycle. > >> > >> > >> * November 8th > >> If we agree to have 3 stages, alpha3 must be released. After this > >> date we start to be stricter about the patches for a while. > >> > >> Patches which should go into this or the next release: > >> - [PATCH] struct argv overhaul > >> <http://bit.ly/2ebnhKz> > >> > >> - [PATCH] Refactor CRL handling > >> <http://bit.ly/2eYUMkK> > >> Also look at the CRL patches from Antonio as well. > >> > >> - [PATCH 0/2] auth-gen-token: Inform client why auth-token was > >> rejected > >> <http://bit.ly/2f7GEJ3> > >> > >> - [PATCH] systemd: Improve the systemd unit files > >> <http://bit.ly/2eboMIq> > >> > >> > >> * November 16th > >> Release first beta. No new features allowed, stabilising > >> starts for real. Some minor "nice to have patches" might be > >> accepted after evaluation/discussion on IRC. > >> > >> Patch to consider: > >> - Add --bind-dev option (Linux VRF + *BSD IP_SENDIF) > >> <http://bit.ly/2e02v5f> (Patch on github) > >> <http://bit.ly/2ebo2mU> (Mail-archive.com thread) > >> > >> > >> * November 23rd (optional) > >> Release second beta. Only patches related to stabilising and > >> important bug-fixes are allowed after this point. No more "nice to > >> have patches" after this point. > >> > >> > >> * December 1st > >> First pre-release (3rd beta or 1st rc) > >> Only really needed and critical bug fixes allowed. This is also the > >> time where we change to a unified coding style across the whole > >> source code. > >> > >> > >> * December 15th > >> Final pre-release (beta/rc) before v2.4.0. > >> Branching out release/2.4 happens here. > >> > >> Reason: We need to ensure people will have at least _some_ time to > >> test before Christmas and some have the ability to run tests > >> during the last weeks of December. > >> > >> > >> * January 4th, 2017 > >> Final release of v2.4.0 > >> > >> > >> The list of patches are the most recent ones I spotted on the mailing > >> list which seems relevant. We might consider other patches too, my > >> patch list is just a proposal. > >> > >> One remark to one the patches: The VRF patches I consider for v2.4 just > >> because this seems very useful and doesn't add a very complicated patch. > >> Considering that 2.4 will live in Debian for a long while, that > >> platform can make most out of this patch as well. In addition, the > >> feature is well isolated from the rest of the code. > >> > >> To manage such a schedule, we really need to ensure patches gets > >> reviewed and ACKed ASAP to be sure things gets included. It will > >> require some efforts from everyone. > >> > >> > >> Any thoughts or comments? > >> > > We should talk with the debian maintainer and ask what we have to do to > > get 2.4.0 into the new debian. Obviously if he/she does not package > > OpenVPN in time we still loose. > > > > Arne > > I already did. I mentioned that on the IRC yesterday evening. No > response from Alberto so far. >
Hi there! I'll go for an upload of 2.4-(beta/rc) to Debian unstable in December. Packages take 6 days to move from unstable to testing (aka Stretch), so if we want 2.4 in Stretch it has to be uploaded at the end of December. I can upload fixes later if needed. I don't know if 2.4 addresses building with openssl 1.1 [1], but that would be a plus. Regards, Alberto [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828477 -- Alberto Gonzalez Iniesta | Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred | http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55 ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel