Please, do not use the issue tracker for support questions. If you have
questions on how to use GLib effectively, you can use:
- - the `#gtk+` IRC channel on irc.gnome.org
- - the [gtk](https://mail.gnome.org/mailman/listinfo/gtk-list) mailing list,
- for general questions on GLib
- - the [gtk-devel](https://mail.gnome.org/mailman/listinfo/gtk-devel-list)
- mailing list, for questions on developing GLib itself
+ - the `#gtk` channel on [Matrix](https://wiki.gnome.org/GettingInTouch/Matrix)
+ - the [`glib` tag on GNOME's Discourse](https://discourse.gnome.org/tags/glib)
You can also look at the [`glib` tag on Stack
Overflow](https://stackoverflow.com/questions/tagged/glib).
### Security issues
-You should not open a new issue for security related questions.
+You **must not** open a new public issue for security related concerns.
-When in doubt, send an email to the [security](mailto:security@gnome.org)
-mailing list.
+Instead, see the [`SECURITY.md` documentation](./SECURITY.md).
### Bug reports
another code base for a while, to gain real-life experience with them before
they are imported into GLib and marked as stable.
+Many APIs and features may be best implemented in another library, unless they
+will be useful for a significant number of applications. GLib does not, and
+cannot, grow its API surface forever. APIs which integrate well with existing
+GLib API, or which extend it to allow it to be integrated better with other
+libraries, are more likely to be accepted than self-contained new APIs or
+features which can easily exist outside of GLib.
+
Each feature should also come fully documented, and with tests which approach
full branch coverage of the new code. GLib’s CI system generates code coverage
-reports which are viewable for each merge request.
+reports which are viewable for each merge request. See
+[the testing policy](./docs/testing.md) for more details.
If proposing a large feature or change, it’s better to discuss it (on the
-`#gtk+` IRC channel or on the
-[gtk-devel](https://mail.gnome.org/mailman/listinfo/gtk-devel-list) mailing
-list) before putting time into writing an actionable issue — and certainly
-before putting time into writing a merge request.
+`#gtk` Matrix channel or on [Discourse](https://discourse.gnome.org) before
+putting time into writing an actionable issue — and certainly before putting
+time into writing a merge request.
## Your first contribution
- Meson
- Ninja
- Gettext (19.7 or newer)
- - a [C99 compatible compiler](https://wiki.gnome.org/Projects/GLib/CompilerRequirements)
+ - a [C99 compatible compiler](./docs/toolchain-requirements.md)
Up-to-date instructions about developing GNOME applications and libraries
can be found on [the GNOME Developer Center](https://developer.gnome.org).
$ cd glib
```
-**Note**: if you plan to push changes to back to the main repository and
-have a GNOME account, you can skip the fork, and use the following instead:
-
-```sh
-$ git clone git@gitlab.gnome.org:GNOME/glib.git
-$ cd glib
-```
-
To compile the Git version of GLib on your system, you will need to
configure your build using Meson:
```sh
-$ meson _builddir .
-$ cd _builddir
-$ ninja
+$ meson setup _builddir .
+$ meson compile -C _builddir
```
Typically, you should work on your own branch:
With each code review, we intend to:
0. Identify if this is a desirable change or new feature. Ideally for larger
- features this will have been discussed (in an issue, on IRC, or on the
- mailing list) already, so that effort isn’t wasted on putting together merge
- requests which will be rejected.
+ features this will have been discussed (in an issue, on Matrix, or on Discourse)
+ already, so that effort isn’t wasted on putting together merge requests
+ which will be rejected.
0. Check the design of any new API.
0. Provide realistic estimates of how long a review might take, if it can’t
happen immediately.
adequately tested, either through requiring tests to be submitted at the
same time, or as a follow-up.
0. Ensure that all new APIs are documented and have [introspection
- annotations](https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations).
+ annotations](https://gi.readthedocs.io/en/latest/annotations/giannotations.html).
0. Check that the contribution is split into logically separate commits, each
with a good commit message.
0. Encourage further high quality contributions.
If a code review is stalled (due to not receiving comments for two or more
weeks; or due to a technical disagreement), please ping another GLib core
-developer on the merge request, or on IRC, to ask for a second opinion.
+developer on the merge request, or on Matrix, to ask for a second opinion.
### Commit messages
that has been built up over the years, we’d like to ask people contributing to
GLib to follow a few rules:
-0. Never push to the `master` branch, or any stable branches, directly; you
+0. Never push to the `main` branch, or any stable branches, directly; you
should always go through a merge request, to ensure that the code is
tested on the CI infrastructure at the very least. A merge request is
also the proper place to get a comprehensive code review from the core
If you have been contributing to GLib for a while and you don’t have commit
access to the repository, you may ask to obtain it following the [GNOME account
-process](https://wiki.gnome.org/AccountsTeam/NewAccounts).
+process](https://wiki.gnome.org/Infrastructure/NewAccounts).
projects / platform / upstream / glib.git / blobdiff