Krusader has both documentation and manpages.

Not in config.ini, but it would be interesting to see what happens with kde/applications/kate, which contains a manpage and more manuals.

Resulting tarball for Kate:

To reproduce, add the following section to config.ini

[kate]
gitModule   = yes
gitTag      = v16.04.0
mainmodule  = applications
version     = 16.04

The kwrite and katepart doc subfolders are not picked, because the script doesn't know about them. Are they supposed to be in the same tarball? (I would think that the kwrite docs should go in a kwrite tarball?)

In D1574#29234, @elvisangelaccio wrote:

Resulting tarball for Kate:

kate-16.04.tar.xz2 MBDownload

To reproduce, add the following section to config.ini

[kate]
gitModule   = yes
gitTag      = v16.04.0
mainmodule  = applications
version     = 16.04

The kwrite and katepart doc subfolders are not picked, because the script doesn't know about them. Are they supposed to be in the same tarball? (I would think that the kwrite docs should go in a kwrite tarball?)

They should be, as they are part of the kate tarballs (including kwrite, it's from the same repository).
The autodetection of the available documents is complicated, because they can be anywhere (normally inside doc/ (or docs/), but look inside few pim repositories. So maybe the config file could be extended with pointers to the doc directories.

Autodetection of po file could be done by parsing Messages.sh and getting the generated pot files; it's an hack, but the alternative with the current system, again, is an explicit list of po files.

We are facing the same issues (how to find the files) in the release-team scripts used for Applications, for example.

In D1574#29443, @ltoscano wrote:

In D1574#29234, @elvisangelaccio wrote:

Resulting tarball for Kate:

kate-16.04.tar.xz2 MBDownload

To reproduce, add the following section to config.ini

[kate]
gitModule   = yes
gitTag      = v16.04.0
mainmodule  = applications
version     = 16.04

The kwrite and katepart doc subfolders are not picked, because the script doesn't know about them. Are they supposed to be in the same tarball? (I would think that the kwrite docs should go in a kwrite tarball?)

They should be, as they are part of the kate tarballs (including kwrite, it's from the same repository).
The autodetection of the available documents is complicated, because they can be anywhere (normally inside doc/ (or docs/), but look inside few pim repositories. So maybe the config file could be extended with pointers to the doc directories.

Autodetection of po file could be done by parsing Messages.sh and getting the generated pot files; it's an hack, but the alternative with the current system, again, is an explicit list of po files.

We are facing the same issues (how to find the files) in the release-team scripts used for Applications, for example.

Sounds like someting that could benefit from a metainfo.yaml file, if we had one in every repo. Would it be possible for scripty to add (edit) a list of docs subfolders and po files in this metadata file?

Anyway, if we need to implement this autodetection at the release-scripts level, I think it's better to do it in releaseme rather than create_tarball.

So what do we want to do with this? I think that supporting all the advanced documentation structures should be addressed in a separate patch, so I'm for shipping this (for now).

If I understand it correctly, compared to the current behavior and scope of create_tarball_kf5 (extragear), the changes here do not introduce regressions. Is it correct? If yes, then yes, let's ship this.

In D1574#31971, @ltoscano wrote:

If I understand it correctly, compared to the current behavior and scope of create_tarball_kf5 (extragear), the changes here do not introduce regressions. Is it correct? If yes, then yes, let's ship this.

Correct. The script should be actually more robust now, because it relies on kdoctools_install (which is unit-tested) instead of reinventing the wheel.