Re: Delay in 14.0-RELEASE cycle and blocking items
On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: [...] > A more up-to-date schedule for the 14.0 release will be published in the > near future, though nothing is yet set in stone. > > Thank you for your patience, and for any help in getting us through > these outstanding items. > Just a quick update on this: I am working on the updated draft schedule for 14.0-RELEASE, and will send several teams internally for comments. A new schedule should be expected to be available on the website and announced on these mailing lists within the week, give or take a few days. Thank you again for your patience and the need for the delay. And certainly not to be excluded - thank you to everyone who helped in ironing out the issues blocking 14.0. Glen On behalf of: re@ signature.asc Description: PGP signature
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-15 um 22:36 schrieb Yuri: Yuri wrote: Michael Osipov wrote: Am 2023-05-15 um 22:19 schrieb Yuri: Michael Osipov wrote: Am 2023-05-15 um 21:37 schrieb Glen Barber: On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: Glen, do you see any chance to get this finally merged: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? It seriously affects people (in enterprises) behind a proxy, curl will be a problem and py-requests is already a serious problem. I have bumped the bug, and pinged sef@ and cc'd re@ as a result. I do not see a problem with it, as long as it is a proper fix. Thank you! I have verified the patch back then, will happily re-verify if requested to. I just tried this (without patching): $ cat ~/.login_conf me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar': $ env | egrep 'FOO|BAR|BAZ' BAZ=foo,bar BAR=baz FOO=bar Not in /etc/login.conf: $ grep NO /etc/login.conf :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4 -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\ $ env | grep NO NO_PROXY='localhost Weird, works for me running main-n262913-bee3d4bf8ed5: $ grep NO_PROXY /etc/login.conf :setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\ $ env | grep NO_PROXY NO_PROXY=localhost,*.siemens.net Oh, the fix is in there: commit f32db406504ece1b28f43dc816736e081fe22826 Author: Sean Eric Fagan Date: Sat Jan 14 10:37:31 2023 -0800 Allow a comma-separated list in login class capabilities, by adding a version of strcspn that allows quoting. So what exactly are we talking about here? :-) I am on 12-STABLE, and reported on that. Tried back than on 13, it was broken as well. You might want to try 14 with double quotes and see if it works. If at least one works, docs need to be updated for sure, and also make sure that in single quotes escapes like \c for colon still work. I'll try a VM with a main snapshot as well tomorrow. M
Re: Delay in 14.0-RELEASE cycle and blocking items
Yuri wrote: > Michael Osipov wrote: >> Am 2023-05-15 um 22:19 schrieb Yuri: >>> Michael Osipov wrote: Am 2023-05-15 um 21:37 schrieb Glen Barber: > On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: >> Glen, >> >> do you see any chance to get this finally merged: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? >> >> It seriously affects people (in enterprises) behind a proxy, curl will >> be a problem and py-requests is already a serious problem. >> > > I have bumped the bug, and pinged sef@ and cc'd re@ as a result. > > I do not see a problem with it, as long as it is a proper fix. Thank you! I have verified the patch back then, will happily re-verify if requested to. >>> >>> I just tried this (without patching): >>> >>> $ cat ~/.login_conf >>> me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar': >>> $ env | egrep 'FOO|BAR|BAZ' >>> BAZ=foo,bar >>> BAR=baz >>> FOO=bar >> >> Not in /etc/login.conf: >>> $ grep NO /etc/login.conf >>> :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4 >>> -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\ >>> $ env | grep NO >>> NO_PROXY='localhost > > Weird, works for me running main-n262913-bee3d4bf8ed5: > > $ grep NO_PROXY /etc/login.conf > :setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\ > $ env | grep NO_PROXY > NO_PROXY=localhost,*.siemens.net Oh, the fix is in there: commit f32db406504ece1b28f43dc816736e081fe22826 Author: Sean Eric Fagan Date: Sat Jan 14 10:37:31 2023 -0800 Allow a comma-separated list in login class capabilities, by adding a version of strcspn that allows quoting. So what exactly are we talking about here? :-)
Re: Delay in 14.0-RELEASE cycle and blocking items
Michael Osipov wrote: > Am 2023-05-15 um 22:19 schrieb Yuri: >> Michael Osipov wrote: >>> Am 2023-05-15 um 21:37 schrieb Glen Barber: On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: > Glen, > > do you see any chance to get this finally merged: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? > > It seriously affects people (in enterprises) behind a proxy, curl will > be a problem and py-requests is already a serious problem. > I have bumped the bug, and pinged sef@ and cc'd re@ as a result. I do not see a problem with it, as long as it is a proper fix. >>> >>> Thank you! I have verified the patch back then, will happily re-verify >>> if requested to. >> >> I just tried this (without patching): >> >> $ cat ~/.login_conf >> me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar': >> $ env | egrep 'FOO|BAR|BAZ' >> BAZ=foo,bar >> BAR=baz >> FOO=bar > > Not in /etc/login.conf: >> $ grep NO /etc/login.conf >> :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4 >> -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\ >> $ env | grep NO >> NO_PROXY='localhost Weird, works for me running main-n262913-bee3d4bf8ed5: $ grep NO_PROXY /etc/login.conf :setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\ $ env | grep NO_PROXY NO_PROXY=localhost,*.siemens.net
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-15 um 22:19 schrieb Yuri: Michael Osipov wrote: Am 2023-05-15 um 21:37 schrieb Glen Barber: On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: Glen, do you see any chance to get this finally merged: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? It seriously affects people (in enterprises) behind a proxy, curl will be a problem and py-requests is already a serious problem. I have bumped the bug, and pinged sef@ and cc'd re@ as a result. I do not see a problem with it, as long as it is a proper fix. Thank you! I have verified the patch back then, will happily re-verify if requested to. I just tried this (without patching): $ cat ~/.login_conf me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar': $ env | egrep 'FOO|BAR|BAZ' BAZ=foo,bar BAR=baz FOO=bar Not in /etc/login.conf: $ grep NO /etc/login.conf :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4 -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\ $ env | grep NO NO_PROXY='localhost
Re: Delay in 14.0-RELEASE cycle and blocking items
Michael Osipov wrote: > Am 2023-05-15 um 21:37 schrieb Glen Barber: >> On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: >>> Glen, >>> >>> do you see any chance to get this finally merged: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? >>> >>> It seriously affects people (in enterprises) behind a proxy, curl will >>> be a problem and py-requests is already a serious problem. >>> >> >> I have bumped the bug, and pinged sef@ and cc'd re@ as a result. >> >> I do not see a problem with it, as long as it is a proper fix. > > Thank you! I have verified the patch back then, will happily re-verify > if requested to. I just tried this (without patching): $ cat ~/.login_conf me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar': $ env | egrep 'FOO|BAR|BAZ' BAZ=foo,bar BAR=baz FOO=bar It looks like single-quotes should do the trick, and we simply need to document this?
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-15 um 21:37 schrieb Glen Barber: On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: Glen, do you see any chance to get this finally merged: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? It seriously affects people (in enterprises) behind a proxy, curl will be a problem and py-requests is already a serious problem. I have bumped the bug, and pinged sef@ and cc'd re@ as a result. I do not see a problem with it, as long as it is a proper fix. Thank you! I have verified the patch back then, will happily re-verify if requested to. Michael
Re: Delay in 14.0-RELEASE cycle and blocking items
On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote: > Glen, > > do you see any chance to get this finally merged: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? > > It seriously affects people (in enterprises) behind a proxy, curl will > be a problem and py-requests is already a serious problem. > I have bumped the bug, and pinged sef@ and cc'd re@ as a result. I do not see a problem with it, as long as it is a proper fix. Glen signature.asc Description: PGP signature
Re: Delay in 14.0-RELEASE cycle and blocking items
Thanks Glen, no rush, quality first, it takes time :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Delay in 14.0-RELEASE cycle and blocking items
Glen, do you see any chance to get this finally merged: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ? It seriously affects people (in enterprises) behind a proxy, curl will be a problem and py-requests is already a serious problem. Michael
Re: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]
Mark Millard writes: > Alexey Dokuchaev wrote on > Date: Wed, 03 May 2023 07:53:09 UTC : > >> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >> > ... >> > There is no feasible way we are going to make the branch point of >> > stable/14 in time, with that scheduled for May 12, 2023 with the above >> > points. That said, this is not an all-inclusive list, but the more >> > major items on our radar at the moment. >> >> Does this delay mean we might get Clang 16 in the base? Current 15.0.7 >> hits assertion on one of my ports which had allegedly been fixed in 16. >> Also, AFAIU it comes with better support for modern C++, e.g. ranges. > > These notes are based on using -std=c++20 and llvm16 on > opensuse tumblweed (in early April), which has libc++ > support configurable. They also presume that the FreeBSD > llvm16 update fully adopts the libc++ from llvm16. > (FreeBSD LLVM upgrades do not always do so at the initial > upgrade time.) FWIW, std::ranges in base libc++ 16 (via llvm-16-update branch) works fine at least in emulators/yuzu (c++20) and x11-wm/hyprland (c++23). More can take advantage but currently use a workaround e.g., $ rg -l :devel/range-v3 | sed s,/Makefile,, biology/seqan3 devel/fbthrift editors/imhex lang/solidity net-im/telegram-desktop
Re: Delay in 14.0-RELEASE cycle and blocking items
> Am 03.05.2023 um 18:27 schrieb Glen Barber : > > On Wed, May 03, 2023 at 07:53:09AM +, Alexey Dokuchaev wrote: >> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >>> ... >>> There is no feasible way we are going to make the branch point of >>> stable/14 in time, with that scheduled for May 12, 2023 with the above >>> points. That said, this is not an all-inclusive list, but the more >>> major items on our radar at the moment. >> >> Does this delay mean we might get Clang 16 in the base? >> > > Well, the delay really means we do not currently have OpenSSL 3 in base. > > Glen > I cannot help with this, of course. But out of interest: what are the problems? There was a post on the haproxy mailing-list a while back, linking to some github issue and from what I understood, there are huge performance-problems in there. Rainer
Re: Delay in 14.0-RELEASE cycle and blocking items
On Wed, May 03, 2023 at 07:53:09AM +, Alexey Dokuchaev wrote: > On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: > > ... > > There is no feasible way we are going to make the branch point of > > stable/14 in time, with that scheduled for May 12, 2023 with the above > > points. That said, this is not an all-inclusive list, but the more > > major items on our radar at the moment. > > Does this delay mean we might get Clang 16 in the base? > Well, the delay really means we do not currently have OpenSSL 3 in base. Glen signature.asc Description: PGP signature
Re: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]
On May 3, 2023, at 08:57, Mark Millard wrote: > Alexey Dokuchaev wrote on > Date: Wed, 03 May 2023 07:53:09 UTC : > >> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >>> ... >>> There is no feasible way we are going to make the branch point of >>> stable/14 in time, with that scheduled for May 12, 2023 with the above >>> points. That said, this is not an all-inclusive list, but the more >>> major items on our radar at the moment. >> >> Does this delay mean we might get Clang 16 in the base? Current 15.0.7 >> hits assertion on one of my ports which had allegedly been fixed in 16. >> Also, AFAIU it comes with better support for modern C++, e.g. ranges. > > These notes are based on using -std=c++20 and llvm16 on > opensuse tumblweed (in early April), which has libc++ > support configurable. They also presume that the FreeBSD > llvm16 update fully adopts the libc++ from llvm16. > (FreeBSD LLVM upgrades do not always do so at the initial > upgrade time.) > > __cpp_lib_ranges would go from undefined to 202106 . > C++20 also has a later 202110 . C++23 has 3 later values, > the last being 202211 . (I'm generally omitting the L > suffixes in my materials.) > > A couple of the C++20 ranges versions are late, > retroactive fixes ["(DR)"s] for things that > could not wait for C++23: > > __cpp_lib_ranges -- 202106 (C++20) (DR) > __cpp_lib_ranges -- 202110 (C++20) (DR) > > So only the 202106 one was in llvm16 when I tested > llvm16. (If I remember right, using -std=c++23 got > the 202110 fix as well.) > > Other libc++ things going from undefined to a defined > status are: > > __cpp_lib_constexpr_complex > __cpp_lib_constexpr_vector > __cpp_lib_memory_resource > __cpp_lib_polymorphic_allocator > __cpp_lib_source_location > > It does not appear that any other __cpp_lib_... macros > would change values for -std=c+=20 use. Typo fix to the above: -std=c++20 > As for the overall status for ranges . . . > > C++23 has lots of changes/additions for ranges: > (The --'s indicate being undefined in llvm15.) I should have noted that the MM months below are from/for the standard and are not indications of llvm16 or later of having implemented them for -std=c+=23 . > __cpp_lib_ranges -- 202202 (C++23) > __cpp_lib_ranges -- 202207 (C++23) > __cpp_lib_ranges -- 202211 (C++23) > __cpp_lib_ranges_as_const -- 202207 (C++23) > __cpp_lib_ranges_as_rvalue -- 202207 (C++23) > __cpp_lib_ranges_cartesian_product -- 202207 (C++23) > __cpp_lib_ranges_chunk -- 202202 (C++23) > __cpp_lib_ranges_chunk_by -- 202202 (C++23) > __cpp_lib_ranges_contains -- 202207 (C++23) > __cpp_lib_ranges_enumerate -- 202303 (C++23) > __cpp_lib_ranges_fold -- 202207 (C++23) > __cpp_lib_ranges_iota -- 202202 (C++23) > __cpp_lib_ranges_join_with -- 202202 (C++23) > __cpp_lib_ranges_repeat -- 202207 (C++23) > __cpp_lib_ranges_slide -- 202202 (C++23) > __cpp_lib_ranges_starts_ends_with -- 202106 (C++23) > __cpp_lib_ranges_stride -- 202207 (C++23) > __cpp_lib_ranges_to_container -- 202202 (C++23) > __cpp_lib_ranges_zip -- 202110 (C++23) > > Ranges seems to be an active area of development > across multiple standard vintages. === Mark Millard marklmi at yahoo.com
What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]
Alexey Dokuchaev wrote on Date: Wed, 03 May 2023 07:53:09 UTC : > On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: > > ... > > There is no feasible way we are going to make the branch point of > > stable/14 in time, with that scheduled for May 12, 2023 with the above > > points. That said, this is not an all-inclusive list, but the more > > major items on our radar at the moment. > > Does this delay mean we might get Clang 16 in the base? Current 15.0.7 > hits assertion on one of my ports which had allegedly been fixed in 16. > Also, AFAIU it comes with better support for modern C++, e.g. ranges. These notes are based on using -std=c++20 and llvm16 on opensuse tumblweed (in early April), which has libc++ support configurable. They also presume that the FreeBSD llvm16 update fully adopts the libc++ from llvm16. (FreeBSD LLVM upgrades do not always do so at the initial upgrade time.) __cpp_lib_ranges would go from undefined to 202106 . C++20 also has a later 202110 . C++23 has 3 later values, the last being 202211 . (I'm generally omitting the L suffixes in my materials.) A couple of the C++20 ranges versions are late, retroactive fixes ["(DR)"s] for things that could not wait for C++23: __cpp_lib_ranges -- 202106 (C++20) (DR) __cpp_lib_ranges -- 202110 (C++20) (DR) So only the 202106 one was in llvm16 when I tested llvm16. (If I remember right, using -std=c++23 got the 202110 fix as well.) Other libc++ things going from undefined to a defined status are: __cpp_lib_constexpr_complex __cpp_lib_constexpr_vector __cpp_lib_memory_resource __cpp_lib_polymorphic_allocator __cpp_lib_source_location It does not appear that any other __cpp_lib_... macros would change values for -std=c+=20 use. As for the overall status for ranges . . . C++23 has lots of changes/additions for ranges: (The --'s indicate being undefined in llvm15.) __cpp_lib_ranges -- 202202 (C++23) __cpp_lib_ranges -- 202207 (C++23) __cpp_lib_ranges -- 202211 (C++23) __cpp_lib_ranges_as_const -- 202207 (C++23) __cpp_lib_ranges_as_rvalue -- 202207 (C++23) __cpp_lib_ranges_cartesian_product -- 202207 (C++23) __cpp_lib_ranges_chunk -- 202202 (C++23) __cpp_lib_ranges_chunk_by -- 202202 (C++23) __cpp_lib_ranges_contains -- 202207 (C++23) __cpp_lib_ranges_enumerate -- 202303 (C++23) __cpp_lib_ranges_fold -- 202207 (C++23) __cpp_lib_ranges_iota -- 202202 (C++23) __cpp_lib_ranges_join_with -- 202202 (C++23) __cpp_lib_ranges_repeat -- 202207 (C++23) __cpp_lib_ranges_slide -- 202202 (C++23) __cpp_lib_ranges_starts_ends_with -- 202106 (C++23) __cpp_lib_ranges_stride -- 202207 (C++23) __cpp_lib_ranges_to_container -- 202202 (C++23) __cpp_lib_ranges_zip -- 202110 (C++23) Ranges seems to be an active area of development across multiple standard vintages. === Mark Millard marklmi at yahoo.com
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-03 10:59, schrieb Mina Galić: Is there a chance to get pkgbase into 14.0? If not it will take another X years to have it in 15.0... PkgBase *is* in 14, like it is in 13. The question is just if re@ has the resources (people, time, Hardware) to provide a Repository. Mina Galić Fingers crossed that the resources are available!
Re: Delay in 14.0-RELEASE cycle and blocking items
> Is there a chance to get pkgbase into 14.0? If not it will take another X > years to have it in 15.0... PkgBase *is* in 14, like it is in 13. The question is just if re@ has the resources (people, time, Hardware) to provide a Repository. Mina Galić
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-01 20:14, schrieb Glen Barber: According to the 14.0-RELEASE schedule, the code slush in main and the freeze to the KBI for 14.0 was scheduled for April 25, 2023. As some of you may have noticed, that did not happen. First, and most importantly for 14.0, is the status of the OpenSSL update to version 3. This in itself is reason to delay the schedule until some tangible progress has been made. Yes, some have expressed interest in helping in this area, however at this moment, this is the key blocker. Second is the status of the branch and how it pertains to the recent upstream merge from OpenZFS. Although block_cloning is disabled by default, there have been other regressions discovered (and fixed), but as a whole, I do not feel that we have a solid understanding of the regressions about which we do not know. There is no feasible way we are going to make the branch point of stable/14 in time, with that scheduled for May 12, 2023 with the above points. That said, this is not an all-inclusive list, but the more major items on our radar at the moment. A more up-to-date schedule for the 14.0 release will be published in the near future, though nothing is yet set in stone. Thank you for your patience, and for any help in getting us through these outstanding items. Glen On behalf of: re@ Is there a chance to get pkgbase into 14.0? If not it will take another X years to have it in 15.0...
Re: Delay in 14.0-RELEASE cycle and blocking items
On 3 May 2023, at 09:53, Alexey Dokuchaev wrote: > > On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >> ... >> There is no feasible way we are going to make the branch point of >> stable/14 in time, with that scheduled for May 12, 2023 with the above >> points. That said, this is not an all-inclusive list, but the more >> major items on our radar at the moment. > > Does this delay mean we might get Clang 16 in the base? Current 15.0.7 > hits assertion on one of my ports which had allegedly been fixed in 16. > Also, AFAIU it comes with better support for modern C++, e.g. ranges. https://bugs.freebsd.org/271047 is the exp-run bug for that; it will depend on how much ports fallout there is, and the effort required to fix things. Last time with clang 15 it took quite a while, but I hope it may be somewhat easier this time. For now it looks like the most impactful change is the new default of -std=gnu++17 for C++ mode (like gcc >= 11), since C++17 has actively removed a bunch of things which were deprecated before, for example the 'register' keyword. That tends to break older software, or software which isn't updated very often. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Delay in 14.0-RELEASE cycle and blocking items
On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: > ... > There is no feasible way we are going to make the branch point of > stable/14 in time, with that scheduled for May 12, 2023 with the above > points. That said, this is not an all-inclusive list, but the more > major items on our radar at the moment. Does this delay mean we might get Clang 16 in the base? Current 15.0.7 hits assertion on one of my ports which had allegedly been fixed in 16. Also, AFAIU it comes with better support for modern C++, e.g. ranges. ./danfe
Delay in 14.0-RELEASE cycle and blocking items
According to the 14.0-RELEASE schedule, the code slush in main and the freeze to the KBI for 14.0 was scheduled for April 25, 2023. As some of you may have noticed, that did not happen. First, and most importantly for 14.0, is the status of the OpenSSL update to version 3. This in itself is reason to delay the schedule until some tangible progress has been made. Yes, some have expressed interest in helping in this area, however at this moment, this is the key blocker. Second is the status of the branch and how it pertains to the recent upstream merge from OpenZFS. Although block_cloning is disabled by default, there have been other regressions discovered (and fixed), but as a whole, I do not feel that we have a solid understanding of the regressions about which we do not know. There is no feasible way we are going to make the branch point of stable/14 in time, with that scheduled for May 12, 2023 with the above points. That said, this is not an all-inclusive list, but the more major items on our radar at the moment. A more up-to-date schedule for the 14.0 release will be published in the near future, though nothing is yet set in stone. Thank you for your patience, and for any help in getting us through these outstanding items. Glen On behalf of: re@ signature.asc Description: PGP signature
