the rationale behind switching away from SGML/Docbook is the following:
* SGML is hard to edit for humans
* the output is not much prettier
* the toolchain is not well supported and missing from the build
* the build is not hooked into anywhere, no automation
the reason why RST was chosen:
* it allows for a strong structure like Docbook
* the theme from Read The Docs is pretty
* it also supports mobile devices
* sphinx can easily output to PDF and ePUB formats
* RST is plaintext that can be easily edited and diff'd
* RST can be automatically built by ReadTheDocs and the toolchain is
readily available
* the output is also parsed by Github so documentation can be read
straight from GH
the reason why Markdown was not chosen:
* the current strong structure would be hard to replicate
* markdown is not standardized and output varies according to the
implementation
the docs were converted with Pandoc, using the following commands:
mkdir oper-guide
for source in sgml/oper-guide/*.sgml; do
pandoc --toc -s -f docbook -t rst $source -o oper-guide/$(basename $source .sgml).rst
done
cd oper-guide
sphinx-quickstart
git add *.rst make.bat conf.py
git add -f Makefile
git rm -r ../sgml
[merged from d4214e9445d9f9d0f0ede3e09a9f81deee9: doc/sgml/oper-guide/config.sgml]
Links that are 'no-export' are not distributed to the rest of the IRC network (including local peers).
This provides a core primitive for 'anycasting' services (but the actual issue of synchronizing data in
a services package is left to the authors of the services package).
Fix the server connection configuration so that it can simultaneously
handle a hostname/IPv4/IPv6 for connecting and a hostname/IPv4/IPv6
for binding. Maintains backwards compatibility for matching a hostname
with a mask.
Multiple host/vhost entries can be specified and the last value for
each address family is stored. Hostnames that resolve automatically
overwrite the IP address.
Server connections can now be made to either IPv4 or IPv6 at random
as well as preferring a specific address family.
These operate on the SubjectPublicKeyInfo of the certificate, which does
change unless the private key is changed. This allows the fingerprint to
stay constant even if the certificate is reissued.
(The same fingerprint is also used by DANE)
