Add g_regex_get_max_backref() and g_regex_get_capture_count(). (#419371,
[platform/upstream/glib.git] / docs / reference / glib / resources.sgml
1 <refentry id="glib-resources" revision="17 Jan 2002">
2 <refmeta>
3 <refentrytitle>Mailing lists and bug reports</refentrytitle>
4 <manvolnum>3</manvolnum>
5 <refmiscinfo>Mailing lists and bug reports</refmiscinfo>
6 </refmeta>
7
8 <refnamediv>
9 <refname>Mailing lists and bug reports</refname>
10 <refpurpose>
11 Getting help with GLib
12 </refpurpose>
13 </refnamediv>
14
15 <refsect1>
16 <title>Filing a bug report or feature request</title>
17
18 <para>
19 If you encounter a bug, misfeature, or missing feature in GLib, please
20 file a bug report on 
21 <ulink url="http://bugzilla.gnome.org">http://bugzilla.gnome.org</ulink>. 
22 We'd also appreciate reports of incomplete or misleading information in 
23 the GLib documentation; file those against the "docs" component of the "glib"
24 product in Bugzilla.
25 </para>
26
27 <para>
28 Don't hesitate to file a bug report, even if you think we may know
29 about it already, or aren't sure of the details. Just give us as much
30 information as you have, and if it's already fixed or has already been
31 discussed, we'll add a note to that effect in the report.
32 </para>
33
34 <para>
35 The bug tracker should definitely be used for feature requests, it's
36 not only for bugs. We track all GLib development in Bugzilla, so it's
37 the way to be sure the GLib developers won't forget about an issue.
38 </para>
39
40 </refsect1>
41
42 <refsect1>
43 <title>Submitting Patches</title>
44
45 <para>
46 If you develop a bugfix or enhancement for GLib, please file that in
47 Bugzilla as well. Bugzilla allows you to attach files; please attach a
48 patch generated by the <command>diff</command> utility, using the 
49 <option>-u</option> option to make the patch more readable. All patches 
50 must be offered under the terms of the GNU LGPL license, so be sure you 
51 are authorized to give us the patch under those terms.
52 </para>
53
54 <para>
55 If you want to discuss your patch before or after developing it, mail 
56 <ulink url="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org</ulink>. 
57 But be sure to file the Bugzilla report as well; if the patch is only on the 
58 list and not in Bugzilla, it's likely to slip through the cracks.
59 </para>
60
61 </refsect1>
62
63 <refsect1>
64 <title>Mailing lists</title>
65
66 <para>
67 There are several mailing lists dedicated to GTK+ and related
68 libraries. Discussion of GLib generally takes place on these lists.
69 You can subscribe or view the archives of these lists on 
70 <ulink url="http://mail.gnome.org">http://mail.gnome.org</ulink>.
71 </para>
72
73 <para>
74 <variablelist>
75
76 <varlistentry>
77 <term><ulink url="mailto:gtk-list@gnome.org">gtk-list@gnome.org</ulink></term>
78 <listitem><para>
79 gtk-list covers general GTK+ (and GLib) topics; questions about using GLib 
80 in programs, GLib from a user standpoint, announcements of GLib-related projects
81 would all be on-topic. The bulk of the traffic consists of GTK+ programming 
82 questions.
83 </para></listitem>
84 </varlistentry>
85
86 <varlistentry>
87 <term><ulink url="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org</ulink></term>
88 <listitem><para>
89 gtk-devel-list is for discussion of work on GTK+ (and GLib) itself, it is 
90 <emphasis>not</emphasis> for asking questions about how to use GTK+ (or GLib) 
91 in applications. gtk-devel-list is appropriate for discussion of patches, 
92 bugs, proposed features, and so on.
93 </para></listitem>
94 </varlistentry>
95
96 <varlistentry>
97 <term><ulink url="mailto:gtk-doc-list@gnome.org">gtk-doc-list@gnome.org</ulink></term>
98 <listitem><para>
99 gtk-doc-list is for discussion of the <application>gtk-doc</application> 
100 documentation system (used to document GTK+ and Glib), and for work on the GTK+
101 (and GLib) documentation.
102 </para></listitem>
103 </varlistentry>
104
105 </variablelist>
106 </para>
107
108 </refsect1>
109
110
111 </refentry>