OpenCores
URL https://opencores.org/ocsvn/openrisc_me/openrisc_me/trunk

Subversion Repositories openrisc_me

[/] [openrisc/] [trunk/] [gnu-src/] [gdb-6.8/] [gdb/] [CONTRIBUTE] - Blame information for rev 258

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 24 jeremybenn
 
2
                        Contributing to GDB
3
 
4
GDB is a collaborative project and one which wants to encourage new
5
development.  You may wish to fix GDB bugs, improve testing, port GDB
6
to a new platform, update documentation, add new GDB features, and the
7
like. To help with this, there is a lot of documentation
8
available.. In addition to the user guide and internals manual
9
included in the GDB distribution, the GDB web pages also contain much
10
information.
11
 
12
You may also want to submit your change so that can be considered for
13
conclusion in a future version of GDB (see below).  Regardless, we
14
encourage you to distribute the change yourself.
15
 
16
If you don't feel up to hacking GDB, there are still plenty of ways to
17
help!  You can answer questions on the mailing lists, write
18
documentation, find bugs, create a GDB related website (contribute to
19
the official GDB web site), or create a GDB related software
20
package. We welcome all of the above and feel free to ask on the GDB
21
mailing lists if you are looking for feedback or for people to review
22
a work in progress.
23
 
24
Ref: http://www.gnu.org/software/gdb/
25
 
26
Finally, there are certain legal requirements and style issues which
27
all contributors need to be aware of.
28
 
29
o       Coding Standards
30
 
31
        All contributions must conform to the GNU Coding Standard.
32
        Submissions which do not conform to the standards will be
33
        returned with a request to reformat the changes.
34
 
35
        GDB has certain additional coding requirements.  Those
36
        requirements are explained in the GDB internals documentation
37
        in the gdb/doc directory.
38
 
39
        Ref: http://www.gnu.org/prep/standards_toc.html
40
 
41
 
42
o       Copyright Assignment
43
 
44
        Before we can accept code contributions from you, we need a
45
        copyright assignment form filled out and filed with the FSF.
46
 
47
        See some documentation by the FSF for details and contact us
48
        (either via the GDB mailing list or the GDB maintainer that is
49
        taking care of your contributions) to obtain the relevant
50
        forms.
51
 
52
        Small changes can be accepted without a copyright assignment form on file.
53
 
54
        Ref: http://www.gnu.org/prep/maintain.html#SEC6
55
 
56
 
57
o       Submitting Patches
58
 
59
        Every patch must have several pieces of information before we
60
        can properly evaluate it.
61
 
62
        A description of the bug and how your patch fixes this
63
        bug. A reference to a testsuite failure is very helpful. For
64
        new features a description of the feature and your
65
        implementation.
66
 
67
        A ChangeLog entry as plaintext (separate from the patch); see
68
        the various ChangeLog files for format and content. Note that,
69
        unlike some other projects, we do require ChangeLogs also for
70
        documentation (i.e., .texi files).
71
 
72
        The patch itself. If you are accessing the CVS repository use
73
        "cvs update; cvs diff -cp"; else, use "diff -cp OLD NEW" or
74
        "diff -up OLD NEW". If your version of diff does not support
75
        these options, then get the latest version of GNU diff.
76
 
77
        We accept patches as plain text (preferred for the compilers
78
        themselves), MIME attachments (preferred for the web pages),
79
        or as uuencoded gzipped text.
80
 
81
        When you have all these pieces, bundle them up in a mail
82
        message and send it to gdb-patches@sourceware.org. All
83
        patches and related discussion should be sent to the
84
        gdb-patches mailinglist. For further information on the GDB
85
        CVS repository, see the Anonymous read-only CVS access and
86
        Read-write CVS access page.
87
 
88
--
89
 
90
Supplemental information for GDB:
91
 
92
o       Please try to run the relevant testsuite before and after
93
        committing a patch
94
 
95
        If the contributor doesn't do it then the maintainer will.  A
96
        contributor might include before/after test results in their
97
        contribution.
98
 
99
 
100
o       For bug fixes, please try to include a way of
101
        demonstrating that the patch actually fixes something.
102
 
103
        The best way of doing this is to ensure that the
104
        testsuite contains one or more test cases that
105
        fail without the fix but pass with the fix.
106
 
107
        People are encouraged to submit patches that extend
108
        the testsuite.
109
 
110
 
111
o       Please read your patch before submitting it.
112
 
113
        A patch containing several unrelated changes or
114
        arbitrary reformats will be returned with a request
115
        to re-formatting / split it.
116
 
117
 
118
o       If ``gdb/configure.in'' is modified then you don't
119
        need to include patches to the regenerated file
120
        ``configure''.
121
 
122
        The maintainer will re-generate those files
123
        using autoconf (2.13 as of 2000-02-29).
124
 
125
 
126
o       If ``gdb/gdbarch.sh'' is modified, you don't
127
        need to include patches to the generated files
128
        ``gdbarch.h'' and ``gdbarch.c''.
129
 
130
        See ``gdb/configure.in'' above.
131
 
132
 
133
o       When submitting a patch that fixes a bug
134
        in GDB's bug database a brief reference
135
        to the bug can be included in the ChangeLog
136
        vis
137
 
138
        * CONTRIBUTE: Mention PR convention.
139
        Fix PR gdb/4705.
140
 
141
        The text ``PR gdb/4705'' should also be included
142
        in the CVS commit message.  That causes the
143
        patch to automatically be archived with the PR.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.