вт, 1 февр. 2022 г. в 15:35, William Lallemand <[email protected]>:
> On Mon, Jan 31, 2022 at 10:22:01AM +0500, Илья Шипицин wrote: > > > > Hello, > > > > Hello Ilya, > > > 0001 .. 0003 are "pre QUIC" patches > > 0004 .. 0006 are most questionable QUIC part > > 0007 is very simple > > > > > > we can discuss whether BoringSSL should be > > 1) dropped completely > > 2) supported, but no QUIC > > 3) supported for QUIC as well > > > > as for "3)" I've checked current state of QUICTLS, looks like its future > is > > not clear, it is not updated since mid december 2021, also it is not > clear > > whether OpenSSL is going to accept it or not. > > > > thanks, > > Ilya > > > BoringSSL is a burden in term of maintenance, since they only work in a > rolling release mode, we can't offer a real support in maintenancecc > branches. > > The current development team also won't have time to support fully > BoringSSL, the only library we are fully supporting is OpenSSL. > > The other libs are supported as a best effort, but not all features are > available. > > I don't mind merging some patches for improving boringSSL support, but > what's bothering me is building the master with the boringSSL HEAD in > the CI. Because API changes and can broke the build without us doing > anything. > I'm fine with best effort approach. Please merge patches that are appropriate. we'll figure out how to enable CI later. maybe "best effort" status should be documented on wiki, I guess people ask it pretty frequently. > > So if we don't want to be bothered to much we could activate the > boringSSL build weekly or something like that. But I don't want a > reminder each time I pushed that boringSSL broke something. > > Regarding the QUIC patches, I'll let the guys in charge of that decides, > but the development of QUIC in HAProxy is made with quictls currently. > > -- > William Lallemand >
