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.
Add a note asking bug reporters to test with the latest stable version
of GIMP or with dev code (not with old stable versions).
Also add some labels on bug reports and feature requests.
We realize that gitlab doesn't encourage people to give base information
as software version or operating system.
Issue templates are not perfect but better than nothing.
