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
