On Sun, Jun 20, 2021 at 05:20:41PM -0600, Shawn Heisey wrote: > On 6/20/2021 3:16 PM, Lukas Tribus wrote: > > It's a haproxy bug, affecting 2.4 releases, I've filed an issue in our > > tracker: > > > > https://github.com/haproxy/haproxy/issues/1297 > > Almost always when I report a problem I'm having with a mature piece of > software, I expect the issue to be PEBCAK, not an actual bug. Either way, I > really enjoy being a part of an open source community.
Hehe we have no business trying to hide bugs, as they'll affect all of us. It's much better to humbly recognize them and fix them :-) > It took me a while to figure out how to get the proper code branch with git > for 2.4 development. 2.4 is not in development anymore, it's stable (and LTS -- long term supported). Please don't try to do any development on 2.4, you'll only waste your time, because if you want to propose some changes, you'll first be requested to rebase your changes on top of latest development and that could take you a while in certain areas. The right way to participate is to pull the development branch, and update it once in a while (e.g. every time you're going back to your developments, such as once a week). This way if something breaks, chances are that the person who did the breaking change still has fresh memories about it and will be able to help, and instantly fix the trouble or explain how to adapt your code. Do not worry too much for the risk of instabilities, the published code is tested and even the haproxy.org site runs on it. It's quite sufficient for development and even for either a personal site, or one that is properly monitored and operated by skilled admins. > I don't think it's on github. This is the first time > I've seen completely separate repositories for different versions. Not > complaining ... I bet there's a very good reason for it. It precisely is because we don't want to receive pull reqs nor issues on the wrong branch, and github doesn't offer sufficient flexibility to allow to disable PRs on certain branches nor repos. I can't blame them too much for this, it's their core business, they have no reason to offer free hosting and resources with no hopes to see forks and PRs in return that indirectly bring them new users. But overall the current model looks like a good balance offering a good efficiency to everyone. > I wish I knew C a lot better than I do ... That's what about half of the long time contributors started to say before become regular ones, welcome! You'll get back to it easily, do not worry. C is easy to learn (or it wouldn't have lasted 50+ years), it just has a number of traps, but those not using it all day long are extra careful and generally do not fall into them. It's like with parachutes, accidents only affect those routinely using them and who are less careful. > though I expect that for TLS > code, even very strong C skills would leave me clueless without spending > several weeks or months doing a deep dive. I agree. Cryptography code is cryptic, that's the part I understand the least. In addition, OpenSSL is even older than haproxy and has 2.5 decades of evolving API, naming schemes, coding styles and incompatible features behind, that inevitably leave some confusion at plenty of places. HAProxy itself is not exempt from this (it's only in 2.4 that we finally renamed all "sess*" functions that were acting on streams and not sessions). But that's why there are comments in the code to explain what the developer tries to do and why. If you find some areas that are too cryptic and not commented enough, feel free to ask here for precisions. You can even use "git blame" on the file then "git show" on the commit IDs to see who worked last on the lines you don't understand. Sometimes you'll find more explanations in the commit message. If you don't, feel free to ask, that's how it works! Willy
