> 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
