Provide all licenses used in the project in a LICENSES folder and
add SPDX license and copyright information for all files in
accordance with the Reuse Software[0] specification.
The copyright information is based on the file's git history,
using a fairly generous definition of "non-trivial".
As of the spec recommendation, the information is generally added
as comments in the files themselves, except for
- NEWS, README and similar top-level standard files, so that
a SPDX code isn't the first thing people encounter
- files that don't support comments (json) or where they'd
be a bit awkward (.desktop, .service)
- anything under po/, to not interfere with translation teams
Those are covered by a .reuse/dep5 files, except for image assets,
where separate .license files are used (It would be possible to
add comments to SVG files, but I don't trust image editors to
preserve them).
[0] https://reuse.software/
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/224>
The eslint job report its results as artifacts in junit format,
so that gitlab can present them in its UI.
However many psople miss that, and unsuccessfully check the logs
instead.
Address this by using a simplified version of gnome-shell's eslint
wrapper, so we can report results both on stdout and in a file
without re-running the linter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/262>
Filtering errors by changed lines in a merge request means some
errors can slip through, for example when an import becomes unused
but isn't removed.
That's more common than rules changing behind our back, so revert
to running eslint directly again.
This reverts commit 119da3291b.
Since we dropped the legacy configuration, we run eslint directly
instead of via a script. However gnome-shell's variant of the script
also has special treatment of merge requests to only consider errors
in changed lines.
While we strive for zero errors, new errors can appear when we update
eslint or change the configuration. Not blocking merge requests due
to unrelated eslint errors is a good thing, run eslint through a
modified version of the gnome-shell script.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/90
Commit messages should include the full URL to an issue or merge
request to keep associated information easily available in future
log digging.
Jonas came up with a script to enforce that policy for mutter and
gnome-shell. It's an excellent idea, so adopt it here as well.
https://gitlab.gnome.org/GNOME/gnome-shell-extensions/merge_requests/52
Florian Müllner
Jonas ÅdahlandFlorian Müllner
