Re: sequence diagrams in rst documentation

[Johannes Berg <johannes@sipsolutions.net>]

> I general I think, we should not include Java into our toolchains
> even if it is optional. Thats, why I won't vote for
> http://plantuml.com/

Keep in mind though that such a vote may well end up being a vote not
just against plantuml, but also against having sequence diagrams to
start with - at least as far as I'm concerned - since we (rightfully!)
also don't want to start writing our own infrastructure (again). There
aren't many alternatives. Even seqdiag/blockdiag isn't nearly as fully
featured as plantuml.

> IMO a tool which generates SVG would be the best, I have to check
> if I find some or if some of the above could used in this way.

plantuml does create svg :->

Ultimately, I actually think it doesn't matter much whether we add java
or python or whatever to our toolchain.

As soon as we add external dependencies that have to be fulfilled
outside of the kernel git tree, and such fulfilment is easy (as it is
in "sudo apt-get install plantuml python3-sphinxcontrib.plantuml"), it
hardly matters what exactly is behind it.

So ultimately, the way I see it, we essentially have two choices:

 1) we reject external dependencies entirely, shipping everything in
    the tree that we need to build documentation
 2) we accept external dependencies, hopefully finding ways to make
    them optional

In case of 1), which we obviously don't have today since we don't ship
sphinx and everything, we're basically reduced to having very simple
python-only plugins. As far as I'm concerned this will mean that I'm
not adding such diagrams to the kernel documentation, life's too short
to rewrite something like plantuml, and I can't find anything that's
pure python (and fulfilling your - IMHO a bit exaggerated - standards).

In case of 2), as long as it's easy to install on a typical Linux
distro, I think it doesn't actually matter that it's java or whatever
else.

johannes