Lines Matching +full:check +full:- +full:merge +full:- +full:request
15 ------------------------------------------------------------------------------
17 ------------------------------------------------------------------------------
27 ------------------------------------------------------------------------------
29 ------------------------------------------------------------------------------
32 `wayland-devel@lists.freedesktop.org
33 <https://lists.freedesktop.org/mailman/listinfo/wayland-devel>`_ mailing
45 ------------------------------------------------------------------------------
47 ------------------------------------------------------------------------------
61 ------------------------------------------------------------------------------
63 ------------------------------------------------------------------------------
72 $> meson setup --prefix=/usr builddir/
73 $> ninja -C builddir/
74 $> sudo ninja -C builddir/ install
78 ------------------------------------------------------------------------------
80 ------------------------------------------------------------------------------
83 `pre-commit <https://pre-commit.com/>`_ with these commands::
85 $> pre-commit install
86 $> pre-commit install --hook-type pre-push
88 This will check a few things before you commit and/or push to your repos to
91 libinput has a roughly three-parts architecture:
93 - the front-end code which handles the ``libinput_some_function()`` API calls in ``libinput.c``
94 - the generic evdev interface handling which maps those API calls to the
96 - there are device-specific backends which do most of the actual work -
97 ``evdev-mt-touchpad.c`` is the one for touchpads for example.
100 get implemented in the device-specific backend. You only need to touch the
104 <https://who-t.blogspot.com/2019/03/libinputs-internal-building-blocks.html>`_
107 Documentation is in ``/doc/api`` for the doxygen-generated API documentation.
110 sphinx. Simply running ``ninja -C builddir`` will rebuild it and the final
113 ------------------------------------------------------------------------------
115 ------------------------------------------------------------------------------
117 libinput provides a bunch of :ref:`tools` to debug any changes - without
120 The two most useful ones are :ref:`libinput debug-events
121 <libinput-debug-events>` and :ref:`libinput debug-gui <libinput-debug-gui>`.
125 $> sudo ./builddir/libinput-debug-events --verbose
126 $> sudo ./builddir/libinput-debug-gui --verbose
130 trying to debug pointer movement or placement. ``libinput debug-gui`` will
139 :ref:`test-suite`::
141 $> sudo ./builddir/libinput-test-suite
144 :ref:`test-suite` for more info. There are a bunch of other tests that are
145 run by the CI on merge requests, you can run those locally with ::
147 $> sudo ninja -C builddir check
154 ------------------------------------------------------------------------------
156 ------------------------------------------------------------------------------
158 Any patches should be sent via a Merge Request (see the `GitLab docs
159 <https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.htm>`_)
163 Below are the steps required to submit a merge request. They do not
164 replace `learning git <https://git-scm.com/doc>`__ but they should be
167 - `Register an account <https://gitlab.freedesktop.org/users/sign_in>`_ in
169 - `Fork libinput <https://gitlab.freedesktop.org/libinput/libinput/-/forks/new>`_
171 - Get libinput's main repository. git will call this repository ``origin``. ::
175 - Add the forked git repository to your remotes (replace ``USERNAME``
182 - Create a new branch and commit your changes to that branch. ::
184 git switch -C mynewbranch
187 git commit -s
194 - Push your changes to your fork and submit a merge request ::
198 This command will print the URL to file a merge request, you then only
203 Select your branch name to merge and ``libinput/libinput`` ``main`` as target branch.
205 - Verify that the CI completes successfully by visiting the merge request
209 <https://docs.gitlab.com/ee/ci/pipelines/#pipeline-mini-graphs>`__). For
213 A merge request without a successful pipeline may never be looked at by a
216 - If changes are requested by the maintainers, please **amend** the
217 commit(s) and **force-push** the updated branch. ::
221 git commit --amend
222 git push -f gitlab mynewbranch
224 A force-push will re-trigger the CI and notify the merge request that new
229 <https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History>`__
233 ------------------------------------------------------------------------------
235 ------------------------------------------------------------------------------
238 `linear, 'recipe' style history <http://www.bitsnbites.eu/git-history-work-log-vs-recipe/>`_
239 This means that every commit should be small, digestible, stand-alone, and
244 better transformed-view iteration (thanks Hannah!)
256 tests: add view-transform correctness tests
274 ------------------------------------------------------------------------------
276 ------------------------------------------------------------------------------
278 When you re-send patches, revised or not, it would be very good to document the
280 merge request. If you have already received Reviewed-by or Acked-by tags, you
286 `'on commit messages' <http://who-t.blogspot.de/2009/12/on-commit-messages.html>`_
289 ------------------------------------------------------------------------------
291 ------------------------------------------------------------------------------
297 ------------------------------------------------------------------------------
298 Tracking patches and follow-ups
299 ------------------------------------------------------------------------------
308 You should use ``git rebase -i`` to make revisions, so that your patches
313 A common request is to split single large patch into multiple patches. This can
323 that they still individually look good, then force-push your new branch to
324 GitLab. This will update the merge request and notify everyone subscribed to
325 your merge request, so they can review it again.
333 ------------------------------------------------------------------------------
335 ------------------------------------------------------------------------------
337 After submitting your merge request to GitLab, you might receive an email
340 Visit your merge request page and check the `pipeline mini graph
341 <https://docs.gitlab.com/ee/ci/pipelines/#pipeline-mini-graphs>`_ to know which
347 Committed gitlab-ci.yml differs from generated gitlab-ci.yml. Please verify
350 When your merge request modifies the CI templates, you might see this error
352 ``ci-fairy generate-template`` wasn't run.
354 ``.gitlab-ci.yaml`` is auto generated, changes should be made in:
356 - ``.gitlab-ci/ci.template``
358 - ``.gitlab-ci/config.yaml``
361 `ci-fairy <https://freedesktop.pages.freedesktop.org/ci-templates/ci-fairy.html#templating-gitlab-c…
362 to update ``.gitlab-ci.yaml``: ::
364 ci-fairy generate-template
366 Finally, force-push you changes. See :ref:`contributing_submitting_code` for
373 Usually, checking the CI log is enough to catch this errors. However, your merge
374 request is built using different configurations you might have not tested.
379 For example, if an error is found in the ``build-no-libwacom`` step, open the
383 + rm -rf 'build dir'
384 + meson 'build dir' -Dlibwacom=false
388 Use the same flags to fix the issue and force-push you changes. See
395 The test suite is run for your merge request to check for bugs, regressions and
400 :: Failure: ../test/test-touchpad.c:465: touchpad_2fg_scroll_slow_distance(synaptics-t440)
402 See :ref:`test-suite` to learn how to run the failing tests.
404 Once the tests are fixed, force-push you changes. See