Hi Ben, On Wed, Jul 19, 2017 at 09:33:28AM +0000, Ben Shillito wrote: > Hi HaProxy Forum, > > In relation to the build error with 51Degrees library. The data files > associated with Trie are very large and were destroying the performance of > the Git repository. As we believe a very small percentage of users were > actually using the files they are now being distributed separately to GitHub.
Very small or not, the reality is that the documented build procedure for STABLE releases has been broken again without even a prior warning. > See this blog post for full details. > > https://51degrees.com/blog/51degrees-github-repository-housekeeping-important-update Hardly an acceptable explanation for anyone trying to upgrade their haproxy to benefit from the latest security fixes, I'm sorry. Also if it's just a matter of database size, you could imagine distributing the smallest version and providing a conversion utility to turn it into the most appropriate format in field. > If you'd like to continue to use Trie please can you contact us via the web > site at https://51degrees.com/contact-us. We can then advise you further. Then why not try to address the problem by placing the code somewhere online instead of asking every user to have to contact you ? > There are no plans to alter the distribution of the Pattern algorithm as the > files are substantially smaller and work well with Git. All HAProxy builds > should continue to work with the Pattern option. Just like HAProxy the open > source business model is at the core of what we do. So in short what you're saying is that the Trie algorithm that used to be available in opensource and promoted in the documentation as the fastest one is no longer opensource, screwing all its users and forcing them to choose between falling back to the slower Pattern method or not updating haproxy and stay with securiy issues in production. > The v3.2.5 branch has now been republished, this was missed when the > repository was trimmed, so apologies for any backporting problems this has > caused. Thanks, so this will fix version 1.6 but not version 1.7 since last year you provided a patch to replace the API before 1.7.0 release. Can you please also publish the last branch needed to build 1.7 and provide an update for the doc to explain how to build it now ? You have no idea of the pain you cause to everyone by constantly breaking stable versions, really! And this throws a discredit on haproxy as a stable product! Please use branches and stop referencing your development branch as the official one! > Willy; we're unsure what you mean by "broke the stable series *AGAIN*" and > "betrayed". Very simple : you did this already one year ago in the middle of haproxy 1.6 when the public code API was suddenly replaced in an incompatible way, causing quite some pain by then already. Users pick a version, they deploy it, prepare their update processes and don't have to think about it anymore, trusting all of us to deliver timely updates that they can deploy quickly. In your case, once in a while they discover that some code broke, they have to revisit their build process to adapt to a different branch, after waiting for some time for the previous code to be made available again, etc. This happened twice in haproxy's existence, and the two times it came from your software. It's not serious. > Could you provide further information so we can see if there's a > harmonious way forward if we've made an innocent mistake? The proper way to deliver a library is to version it. While you can encourage your users to test the development branch at their own risk, any user should be able to rely on a stable branch which only provides fixes. Thus for example if "3.2" is your software branch corresponding to a stable API code, create such a branch in your repository, document how to use this one for a given program, try to plan for an end of life so that your users know whether they're going to use it or not, and simply provide fixes there. You'll note over time that it requires less work and allows you to break more in the master branch since nobody relies on it for anything sensitive. Your software will evolve faster and your users will be happy to be able to trust it. Thanks, Willy
