]>
Commit | Line | Data |
---|---|---|
1 | -*- mode: text; -*- | |
2 | ||
3 | $Id: HACKING,v 1.6 2004/05/13 13:38:06 paul Exp $ | |
4 | ||
5 | GUIDELINES FOR HACKING ON QUAGGA | |
6 | ||
7 | [this is a draft in progress] | |
8 | ||
9 | Generally, GNU coding standards apply. The indentation style is a bit | |
10 | different from standard GNU style, and the existing style should be | |
11 | maintained and used for new code. | |
12 | ||
13 | Be particularly careful not to break platforms/protocols that you | |
14 | cannot test. | |
15 | ||
16 | New code should have good comments, and changes to existing code | |
17 | should in many cases upgrade the comments when necessary for a | |
18 | reviewer to conclude that the change has no unintended consequences. | |
19 | ||
20 | CHANGELOG | |
21 | ||
22 | Add a ChangeLog entry whenever changing code, except for minor fixes | |
23 | to a commit (with a ChangeLog entry) within the last few days. | |
24 | ||
25 | There is at present a mixed style for ChangeLog, with some changes | |
26 | being described in per-directory ChangeLog files, and some at top | |
27 | level. | |
28 | ||
29 | [TBD: resolve per-dir vs top-level, perhaps by reading GNU coding | |
30 | standards] | |
31 | ||
32 | PATCH SUBMISSION | |
33 | ||
34 | * Send a clean diff against the head of CVS in unified diff format, eg by: | |
35 | cvs <cvs opts> diff -uwb .... | |
36 | ||
37 | * Include ChangeLog and NEWS entries as appropriate before the patch | |
38 | (or in it if you are 100% up to date). | |
39 | ||
40 | * Inclue only one semantic change or group of changes per patch.p | |
41 | ||
42 | * Do not make gratuitous changes to whitespace. See the w and b arguments | |
43 | to diff. | |
44 | ||
45 | * State on which platforms and with what daemons the patch has been | |
46 | tested. Understand that if the set of testing locations is small, | |
47 | and the patch might have unforeseen or hard to fix consequences that | |
48 | there may be a call for testers on quagga-dev, and that the patch | |
49 | may be blocked until test results appear. | |
50 | ||
51 | If there are no users for a platform on quagga-dev who are able and | |
52 | willing to verify -current occasionally, that platform may be | |
53 | dropped from the "should be checked" list. | |
54 | ||
55 | PATCH APPLICATION TO CVS | |
56 | ||
57 | * Only apply patches that meet the submission guidelines. | |
58 | ||
59 | * If a patch is large (perhaps more than 100 new/changed lines), tag | |
60 | the repository before and after the change with e.g. before-foo-fix | |
61 | and after-foo-fix. | |
62 | ||
63 | * If the patch might break something, issue a call for testing on the | |
64 | mailinglist. | |
65 | ||
66 | * Give an appropriate commit message, eg the ChangeLog entry should suffice, | |
67 | if it does not, then the ChangeLog entry itself needs to be corrected. | |
68 | ||
69 | * By committing a patch, you are responsible for fixing problems | |
70 | resulting from it (or backing it out). | |
71 | ||
72 | STABLE PLATFORMS AND DAEMONS | |
73 | ||
74 | The list of platforms that should be tested follow. This is a list | |
75 | derived from what quagga is thought to run on and for which | |
76 | maintainers can test or there are people on quagga-dev who are able | |
77 | and willing to verify that -current does or does not work correctly. | |
78 | ||
79 | BSD (Free, Net or Open, any platform) # without capabilities | |
80 | GNU/Linux (any distribution, i386) | |
81 | [future: some 64-bit machine, e.g. NetBSD/sparc64] | |
82 | [Solaris? (could address 64-bit issue)] | |
83 | ||
84 | The list of daemons that are thought to be stable and that should be | |
85 | tested are: | |
86 | ||
87 | zebra | |
88 | bgpd | |
89 | ripd | |
90 | ospfd | |
91 | ripngd | |
92 | ||
93 | IMPORT OR UPDATE VENDOR SPECIFIC ROUTING PROTOCOLS | |
94 | ||
95 | The source code of Quagga is based on two vendors: | |
96 | ||
97 | zebra_org (http://www.zebra.org/) | |
98 | isisd_sf (http://isisd.sf.net/) | |
99 | ||
100 | In order to import source code, the following procedure should be used: | |
101 | ||
102 | * Tag the Current Quagga CVS repository: | |
103 | ||
104 | cvs tag import_isisd_sf_20031223 | |
105 | ||
106 | * Import the source code into the Quagga's framework. You must not modified | |
107 | this source code. It will be merged later. | |
108 | ||
109 | cd dir_isisd | |
110 | export CVSROOT=:pserver:LOGIN@anoncvs.quagga.net:/var/cvsroot | |
111 | cvs import quagga/isisd isisd_sf isisd_sf_20031223 | |
112 | ---COMMENTS--- | |
113 | Vendor: [isisd_sf] Sampo's ISISd from Sourceforge | |
114 | Tag: [isisd_sf_20031217] Current CVS release | |
115 | --- | |
116 | ||
117 | * Update your Quagga's directory: | |
118 | ||
119 | cd dir_quagga | |
120 | cvs update -dP | |
121 | ||
122 | or | |
123 | ||
124 | cvs co -d quagga_isisd quagga | |
125 | ||
126 | * Merge the code, then commit: | |
127 | ||
128 | cvs commit | |
129 |