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` IRC channel on irc.gnome.org
+ - 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).
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` IRC 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
Each contribution is reviewed by the core developers of the GLib project.
-The [CODE-OWNERS](./docs/CODE-OWNERS) document contains the list of core
+The [CODEOWNERS](./docs/CODEOWNERS) document contains the list of core
contributors to GLib and the areas for which they are responsible; you
should ensure to receive their review and signoff on your changes.
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 IRC, 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.
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