Hi Pieter, On Sat, Dec 15, 2018 at 01:32:49AM +0100, PiBa-NL wrote: > Hi Willy, > > Op 14-12-2018 om 22:32 schreef Willy Tarreau: > > if we manage to get haproxy.org to work reasonably stable this week- > > end, it will be a sign that we can release it. > > There are still several known issues that should be addressed before > 'release' imho. > > - Compression corrupts data(Christopher is investigating): > https://www.mail-archive.com/haproxy@formilux.org/msg32059.html
This one was fixed, he had to leave quickly last evening so he couldn't respond, but it was due to some of my changes to avoid copies, I failed to grasp some corner cases of htx. > - Dispatch server crashes haproxy (i found it today): > https://www.mail-archive.com/haproxy@formilux.org/msg32078.html Ah thanks for this one, will check. > - stdout logging makes syslog logging fail (i mentioned it before, but i > thought lets 'officially' re-report it now): > https://www.mail-archive.com/haproxy@formilux.org/msg32079.html I missed this one, I can have a look as well. > - As you mention haproxy serving the haproxy.org website apparently crashed > several times today when you tried a recent build.. Yep, and another bug last time. Some of these ones will ultimately result in new VTC tests being created, but definitely the production is more creative than people when it comes to mixing features and corner cases. > I think a week of > running without a single crash would be a better indicator than a single > week-end that a release could be imminent.?. It should not change much. Currently, bugs happen in no less than 2 hours, this basically represents the interval during which ~100% of the config's features are covered by regular traffic. Longer delays are only useful to detect leaks, which are always possible in other conditions anyway. > - Several of the '/checks/' regtests don't work. Might be a problem with > varnishtest though, not sure.. But you already discovered that. Yes, it's varnishtest which crashes in the libc, I suspect the regexes used might be too heavy for some regex implementations. > And thats just the things i am aware off a.t.m.. That's it for me as well (your two issues are the extra ones I missed). > I'm usually not 'scared' to run a -dev version on my production box for a > while and try a few new experimental features that seem useful to me over a > weekend, but i do need to have the idea that it will 'work' as good as the > version i update from, and to me it just doesn't seem there yet. (i would > really like the compression to be functional before i try again..) I totally agree with you. As you know, a release doesn't mean it's bug-free, it means that it's forbidden to bring any change that break compatibility or which adds a feature that is not strictly necessary, thus the focus becomes 100% bug-fixes. I will obviously never encourage anyone to deploy a version when I don't run it myself. But at the same time, I know that if it's good enough for me, there are many people who will consider it surely is good enough for their specific use case. It doesn't mean they will deploy immediately. I generally recommend not to deploy during the first weeks. But when you work on a project where you have to choose a version, you need to know which one will be available at your project's deadline, and having something that slips forever is a big problem as you can't be sure it will be available by then, and this is something I care about as well. > So with still several known bugs to solve imho its not yet a good time to > release it as a 'stable' version already in few days time.?. Based on the nature of the changes, I don't expect to efficiently discover more issues in more time, which means it will have to have more exposure. > Or did i > misunderstand the 'sign' to release, is it one of several signs that needs > to be checked.?. I think a -dev11 or perhaps a -RC if someone likes that > term, would probably be more appropriate, We can possibly do that, but nobody will deploy it during the next few weeks anyway (xmas and new year's vacation), however some people might want to play with it in their lab when there's less activity. And we've been drifting a bit already. > before distro's start including > the new release expecting stability while actually bringing a seemingly > largish potential of breaking some features that used to work. Distros have been used not to pick our first versions, so I'm not worried with this. In addition I already recommended a few of them not to replace an existing version with any 1.9 since it will not be long-term maintained. > So even > current new commits are still introducing new breakage, while shortly before > release i would expect mostly little fixes to issues to get committed. That > 'new' features arn't 100% stable, that might not be a blocker. But existing > features that used to work properly should imho not get released in a broken > state.. I agree with this and that's my goal too, with putting it into production. I'm not a kamikaze, I don't absolutely want to see it running there this week-end. I just know that we'll get much more reports once it's released than before. Waiting an extra week where just you and me are running it brings very little info compared to when more people consider it can be tested in their dev environment. The "me too" effect on bug reports often is very effective to narrow some of them down. As you know I'm quite transparent with the level of assurance I have in a release, I'm not claiming "it's ok now, go with it" but rather "it's still young, be extremely careful and don't put it anywhere you have something sensitive". Thanks! Willy
