Hi all, On Tue, Nov 17, 2020 at 12:10:41AM +0100, Lukas Tribus wrote: > No, but since we *only test* master, this is the only way we get > *some* coverage for the changes we are backporting to stable branches. > After all, a large percentage of them come from master. How do we know > that a fix that we are backporting to 1.8 won't break the build on an > older libc or gcc? There is a chance that this would have failed a > test on master.
I agree with the goal here. This is the same reason I occasionally run a build on an old AIX 5.2 system I have access to. I don't care if it works or not, I just want to see if I changed something without noticing. Many of the compiler optimization bugs for example can be triggered on older systems, the usual ctype bugs are revealed there as well, and many of the non-linux portability issues can be triggered on older libc as well. Trust me, I've been used to seeing haproxy being built on uncommon systems, and sometimes requiring a few tricks, but that's what people needed. > I am very sympathetic to drop support for old systems, *if the > maintenance overhead becomes a burden* - and I don't set this bar > high. Agreed. I'm in favor of no more than a few minutes a month if that still fits. When it becomes a pain (but then why?) we can drop it. I suggest however that we mark it as "allowed to fail" so that it's just indicative and we don't feel guilty not to address such issues quickly. > So, is this about OpenSSL? By the way, RHEL6/CentOS6 are not the only ones affected by the OpenSSL 1.0.2 maintenance mess, there's Ubuntu 16.04 as well, which gets regular maintenance till April 2021 and extended maintenance till April 2024. And yes, I do want to see older versions of openssl continue to work as long as it doesn't come with too high a maintenance cost. Just my two cents, Willy
