Hi Vincent! On Sat, May 04, 2019 at 01:57:06PM +0200, Vincent Bernat wrote: > ? 29 avril 2019 11:04 +02, Christopher Faulet <cfau...@haproxy.com>: > > > HAProxy 1.8.20 was released on 2019/04/25. It added 48 new commits > > after version 1.8.19. > > Hey! > > Debian Buster will soon be released (nobody knows exactly when, but we > are in full freeze since 2 months). It currently contains HAProxy > 1.8.19. I don't think it would be possible to push 1.8.20 as is. > > We can either keep 1.8.19 as is or select a few critical patches to > apply on it. For example, we could take the MAJOR patches: > > BUG/MAJOR: checks: segfault during tcpcheck_main > BUG/MAJOR: http_fetch: Get the channel depending on the keyword used > BUG/MAJOR: listener: Make sure the listener exist before using it. > BUG/MAJOR: spoe: Fix initialization of thread-dependent fields > BUG/MAJOR: stats: Fix how huge POST data are read from the channel > > And maybe: > > BUG/MEDIUM: listener: make sure the listener never accepts too many conns > > The more changes, the less likely the release team will accept the > change. Assuming we can only make one proposition (which is not true), > what would you (as upstream) try? 1.8.19, one bug, all major bugs, even > more bugs, or 1.8.20?
As you know, I'm strongly opposed to cherry-picking only a small selection of bug fixes that are supposedly more important than other ones in certain environments while some users will only be affected by the ones not picked, because it means that you will deliberately ship known bugs to your users and put them at risk, which is really sad. For the vast majority of users, a deadlock in production caused by an unlikely bug is way more serious than a segfault which "cleanly" gets rid of the faulty process. In addition no single branch exists showing that only a random selection of patches works fine without the other ones, which means you can actually end up with debian-specific regressions caused exclusively by this bad practice. So I'd suggest to insist on having the up to date version (even 1.8.21 if we have a reason to have this one released by then). In the worst case, if this is rejected for whatever reason, it's better to leave a well known version there and continue to encourage every user to switch to your up to date PPA than making them believe their version contains the essential fixes, which would be misleading. Just my two cents, Willy
