- Fix bug-in-waiting when adding more than one TAP event type
[openocd.git] / PATCHES
1 // This file is part of the Doyxgen Developer Manual
2 /** @page patchguide Patch Guidelines
3
4 Please mail patches to: @par
5         openocd-development@lists.berlios.de
6
7 Note that you can't send patches to that list unless
8 you're a member, despite what the list info page says.
9
10 @section Patch Guidelines in a Nutshell
11
12 The patch should be against svn trunk using an SVN
13 diff. If you use git-svn, a git diff or patch is OK
14 too; likewise a quilt patch, if you use quilt.
15
16 It should be a "good patch": focus it on a single
17 issue, and make it be easily reviewable. Don't make
18 it so large that it's hard to review; split large
19 patches into smaller ones. (That can also help
20 track down bugs later on.) All patches should
21 be "clean", which includes preserving the existing
22 coding style and updating documentation as needed.j
23
24 Attach the patch to the email as a .txt file and
25 also write a short change log entry that maintainers
26 can copy and paste into the commit message
27
28 Say if it's a bugfix (describe the bug) or a new
29 feature. Don't expect patches to merge immediately
30 for the next release. Be ready to rework patches
31 in response to feedback.
32
33 Add yourself to the GPL copyright for non-trivial changes.
34
35 To create a patch from the command line:
36 @code 
37         svn diff >mypatch.txt
38 @endcode
39
40 See: @par
41         http://svnbook.red-bean.com/en/1.0/re09.html
42
43 Remember to use "svn add" on new files first: @par
44         http://svnbook.red-bean.com/en/1.0/re01.html
45
46 If you have a decent SVN GUI, then that should be
47 able to create and apply patches as well...
48  
49 @section More Information on Patching
50
51 The @ref primerpatches provides a more complete guide to creating,
52 managing, and contributing patches to the OpenOCD project.
53
54  */
55 /** @file
56 This file contains the @ref patchguide page.
57 */