On Sat, Jun 15, 2019 at 05:46:52PM +0200, Tim Düsterhus wrote: > No objections from my side (and it can always be retrieved back from > git),
Sure, nothing is ever lost, my concern is essentially to be sure I'm not ignoring an obvious use case and annoying some users for no reason. > I'm replying, because I want to suggest to take a look at the > other files in the folder as well: Good point! > - auth.cfg : 10 years and IMO explained well in the > configuration.txt > - check{,.conf} : 12 years > - debug* : 14 years deleted. > - haproxy.init : 4 years kept as it at least serves as a doc to differenciate reload vs restart for simple use cases. > - haproxy.vim : 12 years, apart from my clean-up commit from > last month. Definitely needs to be updated, possibly with some automation. yes I think it's useful to some users. kept for now. > - init.haproxy : 14 years (why is there two 'init' files?!) Deleted. It was used for our distro "formilux" but is even outdated for this one. > - 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. > - stats_haproxy.sh : 12 years I forgot about this one! Pavlos' haproxystats is way more complete and powerful. Let's delete this one. > - transparent_proxy.cfg: Effectively 4 years OK let's keep this one for the time we don't have an updated architecture manual and the wiki is not updated. PiBa contributed this one as it's not obvious. > - wurfl-example.cfg : Recent kept. And I'm moving seamless-reload.txt to doc/ > So if all the outdated files or files with questionable use are removed > a fairly short list remains. The things that are useful (such as > haproxy.vim) could be moved to contrib/ Good point. Now moved to contrib/syntax-highlight. > and the examples folder outright > removed. As history has shown the examples tend to be neglected. Yes, one reason being that the directory used to look like a garbage dump and wasn't quite attractive. > Instead > the configuration.txt should possibly expanded for more complex > use-cases, because that one is actually kept recent. Be careful, configuration.txt should only be a reference manual and theorically should not go beyond simple examples to illustrate a keyword. The rest really belongs to the architecture manual. The difference between the two is simple : - if you start from a config file, you look up keywords in the config manual and you figure their details and limitations ; - 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. So normally there are no "use-cases" in configuration.txt by definition. OK I'm finishing to clear the outdated files now, thanks for pointing these ones! Willy