There hasn’t been a help manual release for GIMP in a long time, but finally I think we are where we can release a new version soon.
We will wait for GIMP’s own 2.10.34 release, which is still pending. To give translators some time, I plan to do this release on February 26, though this is not set in stone.
Note that this concerns the 2.10 branch of the manual, not the master branch. I assume most translators will be aware of this, but if not: we have a daily updated online version of the manual including all translations at https://docs.gimp.org/.
When this release has been done, I plan to start work on future GIMP 3.0 specific changes in the master branch.
looking forward to publication but my memory remembers how a stable release having years waiting for the manual only for the next release to return waiting for new manual
The documentation repository has been basically unmaintained (on the technical side) for many many years. @jboerema took over and reorganized all this, automatized what could be (and is still doing so), set up daily website updates, etc.
So yes, it was bad and people waited releases forever. Now this should be a lot better!
For anyone not limited by bandwidth or other internet related restrictions I would suggest that the online manual is the preferred choice. That way you don’t need to wait for a release. Of course, I understand that this is not feasible for everyone.
Although I have had some help, especially from Anders Jonsson, and occasionally some others, the manual is still lacking in volunteers. We could really use more helping hands
So, if you see something that is outdated or missing information. Don’t hesitate to at least open an issue about it. Even better would be, if you could help write the documentation.
Sure, I agree, there are enough examples of images that don’t bring much extra if the documentation is written well enough. Before removing images though, I think we need to make sure that that is the case.
I think that most of the main menu images, that we use for the menu documentation, can be removed. Instead there should be links to all the menu commands which would be more useful. Docbook generates these for higher levels, but not for the level where we use these. Ideal would be if someone could figure out how to add that, but until then we should probably add them manually.
I’ve seen the new issue and will look at it after releasing the 2.10.34 manual is completed. Besides removing obsolete images (including translated versions), there is nothing else to do. In case you forget a reference to a removed image, the CI build should fail.
The gimp-help release has been delayed a little bit, due to the delay and extra testing needed for GIMP 2.10.34 itself. Hopefully I get around to it one of the next days or this weekend.
Is there any kind of glossary for the GIMP user docs, apart from the stuff under /docs/templates/? If not, where would be the best place for it to reside, and where to best discuss terminology to agree on? I’ve ran across a great variety of terms describing the same thing, biggest issue being the image window menu bar (from multi-window mode times) desperately in need of a better name… maybe “main menu bar”?
With the demise of the mailling lists, this is probably the best place for general discussion, or else discussion can take place in an MR.
I’ve never used the templates much, instead usually copying from a similar documentation page. I was aware that synchronizing the text used multiple times could and should be synchronized.
I think this could either go in documentation-guidelines or else another easily accessible document that can be linked from the README.md. If we want to keep using templates, then they should be mentioned and linked from the relevant document.
I’ll propose expanding the documentation guidelines at some point when I have more grip and overview, facing lots of variations of strings which create more work for translators.
The failure has nothing to do with the content of your MR. If you click on the red cross for the third stage (Build), you can see three build-debian-N out of four failed. Clicking on one of them shows the log and you’ll see it failed to upload something.
If you’re then wondering why there are four build-debian-N tasks, as I was: looking at CI configuration, it seems the reason is to spread the work of building for multiple languages across them.
And to explain even further: as I recall, gimp-help is quite slow to build and would times out (GNOME Gitlab CI jobs are configured to time out after 1 hour). By spreading the work this way, we have 4 smaller builds which don’t time out instead of a huge one which does.
As for random build failure, such as artifacts failing to build, yeah unfortunately it happens. It has nothing to do with our build rule, simply either hardware issues, or network issues, or configuration issues or whatnot. This is up to the admins which take care of the various runners used in GNOME Gitlab. When this happens in a MR for instance, you may just force-trigger a new build and cross your fingers the next build will work fine. If it happens too often, you may report this to GNOME admins with job links and ideally doing a pre-diagnosis of the issue by looking at logs (a good idea is to look at the runner ID on the right side of a job; sometimes some issue are specific to a given runner).
Suggestions for improving the documentation guidelines are always welcome. However, I would prefer using a new topic instead of keeping this topic alive.
the next build will work fine. If it happens too often, you may