From https://gimp.org/bugs/report.html:
> Related to bug reports are enhancement requests. It is recommended to discuss enhancements with developers first, for instance on IRC or in the forums. This is to make sure that the enhancement requests that are filed are well-specified and aligned with the overall goals the developers have for GIMP.
See: d2c4038abd
Our practice of writing everything on the template made the page on gimp-web
fall into oblivion. This was suboptiomal since the template got very big and
hard to read, with many reporters not filling it at all.
So, let's try to improve cleaning the template and directing them to gimp-web,
which have images and such that should clarify how to make good reports.
Following 6245e4ee
In addition to producing testable packages by adding certain labels
(which only developers can do), now we can produce such packages by
adding the same label in the issue description. This facilitates to
non-developers generating such packages (e.g. new GsoC contributors).
Even .sh (Unix) scripts being "forbidden" by us on Meson to
allowing GIMP being 100% natively built on Windows, it is a
good pratice anyway .sh being portable even outside Meson.
Following: 89dfd0161a
Even if some script/tool is common on Windows, it's not wise to
use Win-specific things on Meson if they are avaiable on Python,
since that non-Python code will be too hard to mantain without the
Windows maintainer. So, let's make life easier for non-Win devs.
Meson broadly uses one of the few languages that it is available on
all platforms so let's take advantage of it on internal scripts.
This way, we have only one build language to care (aside Perl, which
have its own purpose) and avoid terrible bugs like: #11385.
Adding some excerpt from our Code of Conduct to be "Considerate and
Respectful". Negative emotions are only making things worse and make
some contributors not even want to interact anymore with some reports.
Also in our MR template, add the mention that we don't want anything
AI-generated in or even anywhere near our project.
Both these topics are things which were recently discussed within the
team (mostly on IRC).
This may help to reduce the number of duplicate reports we get about some (temporarily) frequently reported issues, like the current crash
happening since GLib 2.79/2.80, or the crash happening with older GIMP versions on macOS Sonoma.
This won't be perfect because not everyone will use or read the template, or notice the url in it, or use the url to find and check the
reports, but I count on it getting more known than right now.
* Makes the wording more concise and "first contributor-friendly"
+ Adds info about submitting patches
* Makes the explanation of use cases implicitly mandatory
+ Adds discuss info to facilitate the redation of use cases
… being installed.
There is already most of the main code logic for this, though now plug-ins need
to be in their own subdirectories, which breaks for plug-ins/common/ and
plug-ins/python/, while I needed plug-ins in both these categories to generate
the Windows installer welcome images (file-png, and python-fu-eval in
particular).
Once again, meson was not very helpful, since all its functions still refuse to
output generated files in subdirectories, so I end up duplicating plug-in files
with a custom Python script.
This should fix the CI. It was working on my machine as GIMP was installed, but
such a build rule should work even without GIMP installed.
This will also be useful in the future when we'll want to run unit tests of
plug-ins through the finale GIMP binary itself.
It looks like origin is the same as mr-origin when the contributor
pushes to one's branch. But when a reviewer rebases through the Gitlab
"Rebase" button on web GUI, I got a fatal error:
> fatal: ambiguous argument 'origin/asalle/use-dynamics-flag': unknown
revision or path not in the working tree.
Possibly `origin` is then the remote of the person who rebased (it would
be weird, yet it's a fact the branch is not found). Let's go with this
assumption.
Fixes#950
`.gitlab/search-common-ancestor.sh`'s original authors are
Philip Withnall and Frederic Martinsons.
(Jehan/reviewer's note: script further improved by Asalle)
Use the same syntax as was already in the bug template because some
people are still leaving out the howto text in the middle of their own
bug/feature description.
Apparently the docs changed so the anchor is broken (and contributors
are confused). Also the docs now says that Container Registry is enabled
by default. I assume this must be a recent change which is not available
yet in GNOME's Gitlab instance. So we must ask people to do the opposite
of what the docs says.
