Hello Willy, hello Tim,
On Sat, 15 Jun 2019 at 18:57, Willy Tarreau <[email protected]> wrote: > > - ssl.cfg : 4 years with the most recent commit adding a > > 'verify none' which is questionable. > > deleted, I agree with not spreading bad options by default. I disagree that the amount of the commits and its age are *the* metric to measure the value of an example configuration. It's a fact that we seldom make breaking changes to our config parser, that's a good thing and it's why we don't need to update the example sections for every stable release. We need to measure the merits of an example file based on it's content. A short example configuration does not need frequent updates and it's more useful, the *shorter* it is (as it focuses on one aspect, allowing the user to quickly grasp the config-concept). Of course we need to discuss the removal of obsolete ones, which brings me to the second point: Could we allow some more time for such things to be discussed? A few working days instead of less than 2 hours? I get it, you wanted it done in 2.0, but that's not what I'd call asking for objections. In the specific ssl example, yes, the "verify none" directive does not belong there, instead, it should have been a ca-file directive. Other than that, I don't see neither why this example would be outdated, nor where we could point people asking the extremely specific "howto ssl?" question instead. > As history has shown the examples tend to be neglected. History has also shown that documentation is neglected. But we can point people to specific examples, just as we can point people to documentations. That's why we need examples. To point people to them when they ask. > if you start from the need to implement something, you search > it in the architecture manual and you copy-paste a look-alike > config that you can then extend. I was unaware that that's your intention with the architecture manual, I always saw it as an explanation of basic load-balancing concepts applied to haproxy (principal features like load-balancing and health checking), but I realize now what you mean. However for a 1400 lines document with 4 commits in the last 10 years, all 4 of which typo/spelling fixes only, we cannot exactly claim success. If we want to retire the examples/ directory and put everything in one file, we probably need to revamp the architecture manual completely and create something that Cyril can use for the HTML converter. Otherwise and in its current condition, people are probably not gonna find it, and we'd also have a hard time referencing single examples in there. I'm really not sure if this is all worth it and quite frankly, don't get the problem with single example files in the examples/ directory. Explanations can be inline with the configuration, so it's even lighter to read than an example in the architecture manual. I'm not sure about the gh-wiki, I don't know how it works technically and I'm a bit afraid that we don't have the actual content in *our* git repositories. Also unsure about if we really still own the content once we put it up there. This is different than feature requests or issues, because those are processes that start and end, while architecture guides and everything referenced in the "Proposed plan" is mostly here to stay and they are also *a lot* of work. When I scrolled through the "proposed plan" I felt like this could be the content for 2 or 3 books. Of course, simple example configurations are not that valuable, but still, I'm unsure about that wiki. cheers, lukas
