gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 1 | -*- mode: text; -*- |
| 2 | |
paul | 1f8f61a | 2004-11-05 23:38:20 +0000 | [diff] [blame] | 3 | $Id: HACKING,v 1.10 2004/11/05 23:38:20 paul Exp $ |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 4 | |
| 5 | GUIDELINES FOR HACKING ON QUAGGA |
| 6 | |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 7 | [this is a draft in progress] |
| 8 | |
hasso | 863076d | 2004-09-01 20:13:23 +0000 | [diff] [blame] | 9 | GNU coding standards apply. Indentation follows the result of |
| 10 | invoking GNU indent (as of 2.2.8a) with no arguments. Note that this |
| 11 | uses tabs instead of spaces where possible for leading whitespace, and |
| 12 | assumes that tabs are every 8 columns. Do not attempt to redefine the |
| 13 | location of tab stops. Note also that some indentation does not |
| 14 | follow GNU style. This is a historical accident, and we generally |
| 15 | only clean up whitespace when code is unmaintainable due to whitespace |
| 16 | issues, as fewer changes from zebra lead to easier merges. |
| 17 | |
| 18 | For GNU emacs, use indentation style "gnu". |
| 19 | |
| 20 | For Vim, use the following lines (note that tabs are at 8, and that |
| 21 | softtabstop sets the indentation level): |
| 22 | |
| 23 | set tabstop=8 |
| 24 | set softtabstop=2 |
| 25 | set shiftwidth=2 |
| 26 | set noexpandtab |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 27 | |
gdt | 2934f28 | 2004-01-05 20:09:00 +0000 | [diff] [blame] | 28 | Be particularly careful not to break platforms/protocols that you |
| 29 | cannot test. |
| 30 | |
| 31 | New code should have good comments, and changes to existing code |
| 32 | should in many cases upgrade the comments when necessary for a |
| 33 | reviewer to conclude that the change has no unintended consequences. |
| 34 | |
| 35 | CHANGELOG |
| 36 | |
| 37 | Add a ChangeLog entry whenever changing code, except for minor fixes |
| 38 | to a commit (with a ChangeLog entry) within the last few days. |
| 39 | |
gdt | 18323bb | 2004-11-05 13:17:20 +0000 | [diff] [blame] | 40 | Most directories have a ChangeLog file; changes to code in that |
| 41 | directory should go in the per-directory ChangeLog. Global or |
| 42 | structural changes should also be mentioned in the top-level |
| 43 | ChangeLog. |
gdt | 2934f28 | 2004-01-05 20:09:00 +0000 | [diff] [blame] | 44 | |
paul | 1f8f61a | 2004-11-05 23:38:20 +0000 | [diff] [blame] | 45 | Certain directories do not contain project code, but contain project |
| 46 | meta-data, eg packaging information, changes to files in these directory may |
| 47 | not require the global ChangeLog to be updated (at the discretion of the |
| 48 | maintainer who usually maintains that meta-data). Also, CVS meta-data such |
| 49 | as cvsignore files do not require ChangeLog updates, just a sane commit |
| 50 | message. |
| 51 | |
gdt | b7a97f8 | 2004-07-23 16:23:56 +0000 | [diff] [blame] | 52 | SHARED LIBRARY VERSIONING |
| 53 | |
| 54 | [this section is at the moment just gdt's opinion] |
| 55 | |
| 56 | Quagga builds several shared libaries (lib/libzebra, ospfd/libospf, |
| 57 | ospfclient/libsopfapiclient). These may be used by external programs, |
| 58 | e.g. a new routing protocol that works with the zebra daemon, or |
| 59 | ospfapi clients. The libtool info pages (node Versioning) explain |
| 60 | when major and minor version numbers should be changed. These values |
| 61 | are set in Makefile.am near the definition of the library. If you |
| 62 | make a change that requires changing the shared library version, |
| 63 | please update Makefile.am. |
| 64 | |
| 65 | libospf exports far more than it should, and is needed by ospfapi |
| 66 | clients. Only bump libospf for changes to functions for which it is |
| 67 | reasonable for a user of ospfapi to call, and please err on the side |
| 68 | of not bumping. |
| 69 | |
| 70 | There is no support intended for installing part of zebra. The core |
| 71 | library libzebra and the included daemons should always be built and |
| 72 | installed together. |
| 73 | |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 74 | PATCH SUBMISSION |
| 75 | |
paul | 85cf0a0 | 2004-01-09 16:34:54 +0000 | [diff] [blame] | 76 | * Send a clean diff against the head of CVS in unified diff format, eg by: |
| 77 | cvs <cvs opts> diff -uwb .... |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 78 | |
| 79 | * Include ChangeLog and NEWS entries as appropriate before the patch |
| 80 | (or in it if you are 100% up to date). |
| 81 | |
gdt | 18323bb | 2004-11-05 13:17:20 +0000 | [diff] [blame] | 82 | * Include only one semantic change or group of changes per patch. |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 83 | |
paul | 85cf0a0 | 2004-01-09 16:34:54 +0000 | [diff] [blame] | 84 | * Do not make gratuitous changes to whitespace. See the w and b arguments |
| 85 | to diff. |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 86 | |
| 87 | * State on which platforms and with what daemons the patch has been |
| 88 | tested. Understand that if the set of testing locations is small, |
| 89 | and the patch might have unforeseen or hard to fix consequences that |
| 90 | there may be a call for testers on quagga-dev, and that the patch |
| 91 | may be blocked until test results appear. |
| 92 | |
| 93 | If there are no users for a platform on quagga-dev who are able and |
| 94 | willing to verify -current occasionally, that platform may be |
| 95 | dropped from the "should be checked" list. |
| 96 | |
| 97 | PATCH APPLICATION TO CVS |
| 98 | |
| 99 | * Only apply patches that meet the submission guidelines. |
| 100 | |
| 101 | * If a patch is large (perhaps more than 100 new/changed lines), tag |
| 102 | the repository before and after the change with e.g. before-foo-fix |
| 103 | and after-foo-fix. |
| 104 | |
| 105 | * If the patch might break something, issue a call for testing on the |
| 106 | mailinglist. |
| 107 | |
paul | 4134ceb | 2004-05-13 13:38:06 +0000 | [diff] [blame] | 108 | * Give an appropriate commit message, eg the ChangeLog entry should suffice, |
paul | 1f8f61a | 2004-11-05 23:38:20 +0000 | [diff] [blame] | 109 | if it does not, then the ChangeLog entry itself needs to be corrected. The |
| 110 | commit message text should be identical to that added to the ChangeLog |
| 111 | message. (One suggestion: when commiting, use your editor to read in the |
| 112 | ChangeLog and delete all previous ChangeLogs.) |
paul | 4134ceb | 2004-05-13 13:38:06 +0000 | [diff] [blame] | 113 | |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 114 | * By committing a patch, you are responsible for fixing problems |
| 115 | resulting from it (or backing it out). |
| 116 | |
| 117 | STABLE PLATFORMS AND DAEMONS |
| 118 | |
| 119 | The list of platforms that should be tested follow. This is a list |
| 120 | derived from what quagga is thought to run on and for which |
| 121 | maintainers can test or there are people on quagga-dev who are able |
| 122 | and willing to verify that -current does or does not work correctly. |
| 123 | |
| 124 | BSD (Free, Net or Open, any platform) # without capabilities |
| 125 | GNU/Linux (any distribution, i386) |
paul | 1f8f61a | 2004-11-05 23:38:20 +0000 | [diff] [blame] | 126 | Solaris (strict alignment, any platform) |
gdt | 18323bb | 2004-11-05 13:17:20 +0000 | [diff] [blame] | 127 | [future: NetBSD/sparc64] |
gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 128 | |
| 129 | The list of daemons that are thought to be stable and that should be |
| 130 | tested are: |
| 131 | |
| 132 | zebra |
| 133 | bgpd |
| 134 | ripd |
| 135 | ospfd |
| 136 | ripngd |
gdt | 1f431d2 | 2003-12-22 15:45:01 +0000 | [diff] [blame] | 137 | |
gdt | 18323bb | 2004-11-05 13:17:20 +0000 | [diff] [blame] | 138 | Daemons which are in a testing phase are |
| 139 | |
| 140 | ospf6d |
| 141 | isisd |
| 142 | |
jardin | 9e867fe | 2003-12-23 08:56:18 +0000 | [diff] [blame] | 143 | IMPORT OR UPDATE VENDOR SPECIFIC ROUTING PROTOCOLS |
| 144 | |
| 145 | The source code of Quagga is based on two vendors: |
| 146 | |
| 147 | zebra_org (http://www.zebra.org/) |
| 148 | isisd_sf (http://isisd.sf.net/) |
| 149 | |
gdt | 18323bb | 2004-11-05 13:17:20 +0000 | [diff] [blame] | 150 | [20041105: Is isisd.sf.netf still where isisd word is happening, or is |
| 151 | the quagga repo now the canonical place? The last tarball on sf is |
| 152 | two years old. --gdt] |
| 153 | |
jardin | 9e867fe | 2003-12-23 08:56:18 +0000 | [diff] [blame] | 154 | In order to import source code, the following procedure should be used: |
| 155 | |
| 156 | * Tag the Current Quagga CVS repository: |
| 157 | |
| 158 | cvs tag import_isisd_sf_20031223 |
| 159 | |
| 160 | * Import the source code into the Quagga's framework. You must not modified |
| 161 | this source code. It will be merged later. |
| 162 | |
| 163 | cd dir_isisd |
| 164 | export CVSROOT=:pserver:LOGIN@anoncvs.quagga.net:/var/cvsroot |
| 165 | cvs import quagga/isisd isisd_sf isisd_sf_20031223 |
| 166 | ---COMMENTS--- |
| 167 | Vendor: [isisd_sf] Sampo's ISISd from Sourceforge |
| 168 | Tag: [isisd_sf_20031217] Current CVS release |
| 169 | --- |
| 170 | |
| 171 | * Update your Quagga's directory: |
| 172 | |
| 173 | cd dir_quagga |
| 174 | cvs update -dP |
| 175 | |
| 176 | or |
| 177 | |
| 178 | cvs co -d quagga_isisd quagga |
| 179 | |
| 180 | * Merge the code, then commit: |
| 181 | |
| 182 | cvs commit |
| 183 | |