docs: Point people at the right place for bugs

We don't use Bugzilla for GTK any more, so our documentation should
reflect that change.

Closes #1559
This commit is contained in:
Emmanuele Bassi 2019-01-09 12:21:08 +00:00
parent ba1644cba1
commit a5fcdca935
2 changed files with 27 additions and 23 deletions

View File

@ -77,8 +77,8 @@ specific widgets and functions.
<para>
If you have a question not covered in the manual, feel free to
ask on the mailing lists and please <ulink
url="https://bugzilla.gnome.org">file a bug report</ulink> against the
documentation.
url="https://gitlab.gnome.org/GNOME/gtk/issues/new">file a bug report</ulink>
against the documentation.
</para>
</answer>
@ -105,8 +105,8 @@ state (explained in its documentation).
For strings returned from functions, they will be declared "const"
if they should not be freed. Non-const strings should be
freed with g_free(). Arrays follow the same rule. If you find an
undocumented exception to the rules, please report a bug to <ulink
url="https://bugzilla.gnome.org">https://bugzilla.gnome.org</ulink>.
undocumented exception to the rules, please
<ulink url="https://gitlab.gnome.org/GNOME/gtk/issues/new">file a bug report</ulink>.
</para>
</answer>

View File

@ -17,15 +17,14 @@ Getting help with GTK+
</refnamediv>
<refsect1>
<title>Filing a bug report or feature request</title>
<title>Opening a bug or feature request</title>
<para>
If you encounter a bug, misfeature, or missing feature in GTK+, please
file a bug report on
<ulink url="https://bugzilla.gnome.org">https://bugzilla.gnome.org</ulink>.
We'd also appreciate reports of incomplete or misleading information in
the GTK+ documentation; file those against the "docs" component of the "gtk+"
product in Bugzilla.
file a bug report on our
<ulink url="https://gitlab.gnome.org/GNOME/gtk/issues/new">GitLab project</ulink>.
You should also file issues if the documentation is out of date with the
existing API, or unclear.
</para>
<para>
@ -37,29 +36,34 @@ discussed, we'll add a note to that effect in the report.
<para>
The bug tracker should definitely be used for feature requests, it's
not only for bugs. We track all GTK+ development in Bugzilla, so it's
the way to be sure the GTK+ developers won't forget about an issue.
not only for bugs. We track all GTK+ development in GitLab, to ensure
that nothing gets lost.
</para>
</refsect1>
<refsect1>
<title>Submitting Patches</title>
<title>Working on GTK+</title>
<para>
If you develop a bugfix or enhancement for GTK+, please file that in
Bugzilla as well. Bugzilla allows you to attach files; please attach a
patch generated by the <command>diff</command> utility, using the
<option>-u</option> option to make the patch more readable. All patches
must be offered under the terms of the GNU LGPL license, so be sure you
are authorized to give us the patch under those terms.
If you develop a bugfix or enhancement for GTK+, please open a merge
request in GitLab as well. You should not attach patches to an issue,
or describe the fix as a comment. Merge requests allow us to build
GTK+ with your code applied, and run the test suite, on multiple platforms
and architectures, and verify that nothing breaks. They also allow us to
do proper code reviews, so we can iterate over the changes.
</para>
<para>
If you want to discuss your patch before or after developing it, mail
<ulink url="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org</ulink>.
But be sure to file the Bugzilla report as well; if the patch is only on the
list and not in Bugzilla, it's likely to slip through the cracks.
You should follow the <ulink url="https://gitlab.gnome.org/GNOME/gtk/blob/master/CONTRIBUTING.md">contribution guide</ulink>
for GTK+, available on GitLab.
</para>
<para>
If you want to discuss your approach before or after working on it,
send and email to <ulink url="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org</ulink>.
You should not send a patch to the mailing list, as it will inevitably
get lost, or forgotten. Always open a merge request.
</para>
</refsect1>