Lines Matching +full:check +full:- +full:merge +full:- +full:request

16  - bug reporting and fixing
17  - documentation and examples
18  - tests
19  - testing and support for other platforms
20  - new features
25  - the `#gtk` IRC channel on irc.gnome.org
26  - the [`glib` tag on GNOME's Discourse](https://discourse.gnome.org/tags/glib)
51  0. a small, self-contained example exhibiting the behavior
61     memcheck](http://valgrind.org/docs/manual/mc-manual.html)
65  - spelling/grammar fixes in the documentation,
66  - typo correction,
67  - comment clean ups,
68  - changes to metadata files (CI, `.gitignore`),
69  - build system changes, or
70  - source tree clean ups and reorganizations;
72 or for self-contained bug fixes where you have implemented and tested a solution
73 already, you should directly open a merge request instead of filing a new issue.
88 allows us to check that the new APIs are usable in real-life code, and fit well
93 another code base for a while, to gain real-life experience with them before
98 reports which are viewable for each merge request.
103 time into writing a merge request.
112  - Python 3.x
113  - Meson
114  - Ninja
115  - Gettext (19.7 or newer)
116  - a [C99 compatible compiler](https://wiki.gnome.org/Projects/GLib/CompilerRequirements)
118 Up-to-date instructions about developing GNOME applications and libraries
155 $ git checkout -b your-branch
159 to the Git repository and open a new merge request, to let the GLib
180     already, so that effort isn’t wasted on putting together merge requests
182  0. Check the design of any new API.
187     same time, or as a follow-up.
190  0. Check that the contribution is split into logically separate commits, each
197 developer on the merge request, or on IRC, to ask for a second opinion.
214  - Always add a brief description of the commit to the _first_ line of
218  - First line (the brief description) must only be one sentence and
223  - The main description (the body) is normal prose and should use normal
229  - When committing code on behalf of others use the `--author` option, e.g.
230  `git commit -a --author "Joe Coder <joe@coder.org>"` and `--signoff`.
232  - If your commit is addressing an issue, use the
243  - If you have a merge request with multiple commits and none of them
246  closing syntax in the description of the merge request.
248 ### Merge access to the GLib repository
251 person with write access to the GNOME repository can merge merge requests to
260    should always go through a merge request, to ensure that the code is
261    tested on the CI infrastructure at the very least. A merge request is
267 0. Pay attention to the CI results. Merge requests cannot be merged until the