Hi. I'm not clear on the ins and outs, particularly concerning string freezes, of fixing documentation problems in the KDE 3.x series.
I saw some changes that could be made in the KPatience manual. I started editing to a copy of the Docbook file. I was unsure about a few things, which I'll bring up in a separate e-mail. I'll illustrate what I'm lost about using KPatience as an example. As I understand it: * Everything under the /trunk directory is in active development for KDE4. * Some, not all, applications are also under /branches/$app (or /branches/work/$app for stuff not in core distribution). /branches is for working on the KDE 3.x versions of the applications, so new features of those apps can be added to arrive for users in KDE 3.5x/3.6/7. I saw some tweaks, grammar and the like, that could be made to the present kpat manual while browsing the installed version on my KDE 3.5.5 desktop. Ideally, folks should work on trunk docs. But KDE4 is still a way off. Is there any value in (also?) working on the documentation to benefit users of future KDE 3.x series releases? KPatience is in active development with changes being made to how it works (new keybindings for example) in /trunk. As far as I know it isn't being worked on to make a new version for future KDE 3.x releases as well. Unless I have a working KDE4 development installation to run the current KPatience development version, I won't be easily able to write updated documentation through checking against its changes/new features. However, say I propose clarity/grammar fixes for the current KDE 3.x manual. The manual for the KDE4 version would benefit from these same changes. In other words, working from an updated index.docbook that had already had any earlier wording errors fixed, so only changes like new keybindings or new features normally needed to be added. In the case of kpat, I decided to work on the index.docbook file in /trunk. I did this because a) changes reflecting new features hadn't been added to it yet anyway, and b) I'd make sure to include any wording fixes added since the last KDE release. Bug #103079 is an example of such a fix (though from a while back and already in the KDE 3.x manual). I changed the releaseinfo number to match the application version in the current stable KDE 3.x release. If somebody patching a doc made a diff for each release - branch and trunk, then they'd need a different releaseinfo number in each I suppose. Perhaps it's too late. Will changes to manuals be able to reach users for future KDE 3.x releases, including those apps not simultaneously worked on under a 3.5x branch? Thanks, Richard.
