Meson recommends using the `meson setup [options]` command:
WARNING: Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.
Update the documentation and CI to use the recommended command.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This ensures a few things are correct before we commit and/or push,
making life a bit easier for both our contributors and our maintainers
since some things should no longer end up in the MRs.
Activate via:
$ pre-commit install
$ pre-commit install --hook-type pre-push
The latter is required for the ci-templates hooks which are pre-push
only.
We've had this for roughly 10y now and it's value is dubious. Most of
xorg no longer requires, mesa accepts but doesn't require it, most of GNOME
doesn't accept it and neither does systemd.
Let's drop the requirement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Clarify that when forking libinput the public visibility level should be
selected. Otherwise, CI pipelines will fail on merge requests.
Also, update the fork URL.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Add a section in the contributing documentation with common pipeline
errors and how to fix them and point to this page when the CI fails.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
It wasn't clear about the Signed-of-by requirements, so this has been
improved with an example, and clarifies that it is a requirement, not
optional.
Signed-off-by: William Brown <william@blackhats.net.au>
This makes a small number of changes that can help improve onboarding
and diversity of contributors. Key to point out is that the code of
conduct is now one of the first items, to highlight the community
standards (rather than being at the bottom where it can be
overlooked). The use of the work "hack" often is off putting to
many people, so replaced with "work". Additionally, changed
the introduction to highlight a desire to be inclusive.
A follow up you probably could do, is have a "how to prepare the
development environment" aka "what depenedencies do I need for
my distro to build the project.
Much of this has come from experience working with outreach/diversity
experts, and my own experience on
http://www.port389.org/docs/389ds/contributing.html
Signed-off-by: William Brown <william@blackhats.net.au>
This is mostly taken from the Weston Contributing.md document.
Main changes from there are:
- more detailed step-by-step on how to create a MR
- commit history/messages in two sections
- s/Weston/libinput/
I skipped the Review/Commit Rights sections for now until there's some demand
for it. Same with the Licensing/Stabilising for releases sections.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
This is a large commit because it's difficult to split this up and we don't
care about bisecting here anyway.
doxygen is going to produce the API documentation only
sphinx is going to produce the prose user (and a bit of developer) documentation.
The source split is doc/api and doc/user.
Steps performed:
- run the doxygen-to-sphinx.sh script to convert all .dox sources to .rst
- manually fixed the .rst to render correctly
- add a few extra .rst documents to generate the right hierarchy
- hook up sphinx-build in meson
- add a new @mainpage for doxygen more aimed at developers
For the build directory:
- sphinx produces /Documentation
- doxygen now produces /api/
These need to be manually combined in the wayland-web repo, meson doesn't
support subdirectories as output paths within the build dir and the
documentation doesn't need to be installed anywhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
