]>
Commit | Line | Data |
---|---|---|
e99c37b4 PJ |
1 | --- |
2 | title: Conventions for working on Quagga | |
3 | papersize: a4paper | |
4 | geometry: scale=0.82 | |
5 | fontsize: 11pt | |
6 | toc: true | |
7 | date: \today | |
8 | include-before: | |
9 | \large This is a living document. Suggestions for updates, via the | |
10 | [quagga-dev list](http://lists.quagga.net/mailman/listinfo/quagga-dev), | |
11 | are welcome. \newpage | |
12 | ... | |
fa482834 | 13 | |
e99c37b4 | 14 | \newpage |
fa482834 | 15 | |
e99c37b4 PJ |
16 | GUIDELINES FOR HACKING ON QUAGGA {#sec:guidelines} |
17 | ================================ | |
fa482834 PJ |
18 | |
19 | GNU coding standards apply. Indentation follows the result of | |
e99c37b4 | 20 | invoking GNU indent (as of 2.2.8a) with the -–nut argument. |
db5a0ac1 PJ |
21 | |
22 | Originally, tabs were used instead of spaces, with tabs are every 8 columns. | |
e99c37b4 | 23 | However, tab’s interoperability issues mean space characters are now preferred for |
db5a0ac1 PJ |
24 | new changes. We generally only clean up whitespace when code is unmaintainable |
25 | due to whitespace issues, to minimise merging conflicts. | |
fa482834 PJ |
26 | |
27 | Be particularly careful not to break platforms/protocols that you | |
28 | cannot test. | |
29 | ||
30 | New code should have good comments, which explain why the code is correct. | |
31 | Changes to existing code should in many cases upgrade the comments when | |
32 | necessary for a reviewer to conclude that the change has no unintended | |
33 | consequences. | |
34 | ||
35 | Each file in the Git repository should have a git format-placeholder (like | |
36 | an RCS Id keyword), somewhere very near the top, commented out appropriately | |
e99c37b4 PJ |
37 | for the file type. The placeholder used for Quagga (replacing \<dollar\> |
38 | with \$) is: | |
fa482834 | 39 | |
e99c37b4 | 40 | `$QuaggaId: <dollar>Format:%an, %ai, %h<dollar> $` |
fa482834 PJ |
41 | |
42 | See line 2 of HACKING.tex, the source for this document, for an example. | |
43 | ||
e99c37b4 | 44 | This placeholder string will be expanded out by the ‘git archive’ commands, |
21bbd111 | 45 | which is used to generate the tar archives for snapshots and releases. |
fa482834 PJ |
46 | |
47 | Please document fully the proper use of a new function in the header file | |
48 | in which it is declared. And please consult existing headers for | |
49 | documentation on how to use existing functions. In particular, please consult | |
50 | these header files: | |
51 | ||
e99c37b4 PJ |
52 | <span>lib/log.h</span> logging levels and usage guidance |
53 | ||
54 | <span>[more to be added]</span> | |
fa482834 PJ |
55 | |
56 | If changing an exported interface, please try to deprecate the interface in | |
57 | an orderly manner. If at all possible, try to retain the old deprecated | |
58 | interface as is, or functionally equivalent. Make a note of when the | |
59 | interface was deprecated and guard the deprecated interface definitions in | |
21bbd111 | 60 | the header file, i.e.: |
fa482834 | 61 | |
e99c37b4 PJ |
62 | /* Deprecated: 20050406 */ |
63 | #if !defined(QUAGGA_NO_DEPRECATED_INTERFACES) | |
64 | #warning "Using deprecated <libname> (interface(s)|function(s))" | |
65 | ... | |
66 | #endif /* QUAGGA_NO_DEPRECATED_INTERFACES */ | |
fa482834 PJ |
67 | |
68 | This is to ensure that the core Quagga sources do not use the deprecated | |
69 | interfaces (you should update Quagga sources to use new interfaces, if | |
70 | applicable), while allowing external sources to continue to build. | |
71 | Deprecated interfaces should be excised in the next unstable cycle. | |
72 | ||
73 | Note: If you wish, you can test for GCC and use a function | |
e99c37b4 | 74 | marked with the ’deprecated’ attribute. However, you must provide the |
fa482834 PJ |
75 | warning for other compilers. |
76 | ||
e99c37b4 | 77 | If changing or removing a command definition, *ensure* that you |
fa482834 | 78 | properly deprecate it - use the \_DEPRECATED form of the appropriate DEFUN |
e99c37b4 PJ |
79 | macro. This is *critical*. Even if the command can no longer |
80 | function, you *MUST* still implement it as a do-nothing stub. | |
fa482834 PJ |
81 | |
82 | Failure to follow this causes grief for systems administrators, as an | |
83 | upgrade may cause daemons to fail to start because of unrecognised commands. | |
84 | Deprecated commands should be excised in the next unstable cycle. A list of | |
85 | deprecated commands should be collated for each release. | |
86 | ||
e99c37b4 | 87 | See also section [sec:dll-versioning] below regarding SHARED LIBRARY |
fa482834 PJ |
88 | VERSIONING. |
89 | ||
e99c37b4 PJ |
90 | YOUR FIRST CONTRIBUTIONS |
91 | ======================== | |
1d1c6361 VJ |
92 | |
93 | Routing protocols can be very complex sometimes. Then, working with an | |
94 | Opensource community can be complex too, but usually friendly with | |
95 | anyone who is ready to be willing to do it properly. | |
96 | ||
e99c37b4 PJ |
97 | - First, start doing simple tasks. Quagga’s patchwork is a good place |
98 | to start with. Pickup some patches, apply them on your git trie, | |
99 | review them and send your ack’t or review comments. Then, a | |
100 | maintainer will apply the patch if ack’t or the author will have to | |
101 | provide a new update. It help a lot to drain the patchwork queues. | |
102 | See <http://patchwork.quagga.net/project/quagga/list/> | |
103 | ||
104 | - The more you’ll review patches from patchwork, the more the Quagga’s | |
105 | maintainers will be willing to consider some patches you will be | |
106 | sending. | |
1d1c6361 | 107 | |
e99c37b4 PJ |
108 | - start using git clone, pwclient |
109 | <http://patchwork.quagga.net/help/pwclient/> | |
1d1c6361 | 110 | |
e99c37b4 PJ |
111 | $ pwclient list -s new |
112 | ID State Name | |
113 | -- ----- ---- | |
114 | 179 New [quagga-dev,6648] Re: quagga on FreeBSD 4.11 (gcc-2.95) | |
115 | 181 New [quagga-dev,6660] proxy-arp patch | |
116 | [...] | |
1d1c6361 | 117 | |
e99c37b4 | 118 | $ pwclient git-am 1046 |
1d1c6361 | 119 | |
e99c37b4 PJ |
120 | HANDY GUIDELINES FOR MAINTAINERS |
121 | ================================ | |
1d1c6361 | 122 | |
e99c37b4 | 123 | Get your cloned trie: |
1d1c6361 | 124 | |
e99c37b4 | 125 | git clone vjardin@git.sv.gnu.org:/srv/git/quagga.git |
1d1c6361 | 126 | |
e99c37b4 | 127 | Apply some ack’t patches: |
1d1c6361 | 128 | |
e99c37b4 PJ |
129 | pwclient git-am 1046 |
130 | Applying patch #1046 using 'git am' | |
131 | Description: [quagga-dev,11595] zebra: route_unlock_node is missing in "show ip[v6] route <prefix>" commands | |
132 | Applying: zebra: route_unlock_node is missing in "show ip[v6] route <prefix>" commands | |
133 | ||
134 | Run a quick review. If the ack’t was not done properly, you know who you have | |
1d1c6361 VJ |
135 | to blame. |
136 | ||
137 | Push the patches: | |
e99c37b4 PJ |
138 | |
139 | git push | |
1d1c6361 VJ |
140 | |
141 | Set the patch to accepted on patchwork | |
fa482834 | 142 | |
e99c37b4 PJ |
143 | pwclient update -s Accepted 1046 |
144 | ||
145 | COMPILE-TIME CONDITIONAL CODE | |
146 | ============================= | |
fa482834 PJ |
147 | |
148 | Please think very carefully before making code conditional at compile time, | |
149 | as it increases maintenance burdens and user confusion. In particular, | |
e99c37b4 PJ |
150 | please avoid gratuitous -–enable-… switches to the configure script - |
151 | typically code should be good enough to be in Quagga, or it shouldn’t be | |
152 | there at all. | |
fa482834 PJ |
153 | |
154 | When code must be compile-time conditional, try have the compiler make it | |
155 | conditional rather than the C pre-processor - so that it will still be | |
156 | checked by the compiler, even if disabled. I.e. this: | |
157 | ||
e99c37b4 PJ |
158 | if (SOME_SYMBOL) |
159 | frobnicate(); | |
fa482834 PJ |
160 | |
161 | rather than: | |
162 | ||
e99c37b4 PJ |
163 | #ifdef SOME_SYMBOL |
164 | frobnicate (); | |
165 | #endif /* SOME_SYMBOL */ | |
fa482834 | 166 | |
e99c37b4 PJ |
167 | Note that the former approach requires ensuring that SOME\_SYMBOL will |
168 | be defined (watch your AC\_DEFINEs). | |
fa482834 | 169 | |
e99c37b4 PJ |
170 | COMMIT MESSAGES |
171 | =============== | |
fa482834 PJ |
172 | |
173 | The commit message requirements are: | |
174 | ||
e99c37b4 PJ |
175 | - The message *MUST* provide a suitable one-line summary followed by a |
176 | blank line as the very first line of the message, in the form: | |
fa482834 | 177 | |
e99c37b4 | 178 | `topic: high-level, one line summary` |
fa482834 | 179 | |
e99c37b4 PJ |
180 | Where topic would tend to be name of a subdirectory, and/or daemon, unless |
181 | there’s a more suitable topic (e.g. ’build’). This topic is used to | |
182 | organise change summaries in release announcements. | |
fa482834 | 183 | |
e99c37b4 PJ |
184 | - It should have a suitable “body”, which tries to address the |
185 | following areas, so as to help reviewers and future browsers of the | |
186 | code-base understand why the change is correct (note also the code | |
187 | comment requirements): | |
fa482834 | 188 | |
e99c37b4 | 189 | - The motivation for the change (does it fix a bug, if so which? |
fa482834 | 190 | add a feature?) |
e99c37b4 PJ |
191 | |
192 | - The general approach taken, and trade-offs versus any other | |
fa482834 | 193 | approaches. |
e99c37b4 PJ |
194 | |
195 | - Any testing undertaken or other information affecting the confidence | |
fa482834 | 196 | that can be had in the change. |
e99c37b4 PJ |
197 | |
198 | - Information to allow reviewers to be able to tell which specific | |
fa482834 PJ |
199 | changes to the code are intended (and hence be able to spot any accidental |
200 | unintended changes). | |
201 | ||
fa482834 PJ |
202 | The one-line summary must be limited to 54 characters, and all other |
203 | lines to 72 characters. | |
204 | ||
205 | Commit message bodies in the Quagga project have typically taken the | |
206 | following form: | |
207 | ||
e99c37b4 PJ |
208 | - An optional introduction, describing the change generally. |
209 | ||
210 | - A short description of each specific change made, preferably: | |
211 | ||
212 | - file by file | |
213 | ||
214 | - function by function (use of “ditto”, or globs is allowed) | |
fa482834 PJ |
215 | |
216 | Contributors are strongly encouraged to follow this form. | |
217 | ||
218 | This itemised commit messages allows reviewers to have confidence that the | |
219 | author has self-reviewed every line of the patch, as well as providing | |
220 | reviewers a clear index of which changes are intended, and descriptions for | |
21bbd111 | 221 | them (C-to-english descriptions are not desirable - some discretion is |
fa482834 PJ |
222 | useful). For short patches, a per-function/file break-down may be |
223 | redundant. For longer patches, such a break-down may be essential. A | |
224 | contrived example (where the general discussion is obviously somewhat | |
225 | redundant, given the one-line summary): | |
226 | ||
e99c37b4 PJ |
227 | > zebra: Enhance frob FSM to detect loss of frob |
228 | > | |
229 | > Add a new DOWN state to the frob state machine to allow the barinator to | |
230 | > detect loss of frob. | |
231 | > | |
232 | > * frob.h: (struct frob) Add DOWN state flag. | |
233 | > * frob.c: (frob_change) set/clear DOWN appropriately on state change. | |
234 | > * bar.c: (barinate) Check frob for DOWN state. | |
fa482834 PJ |
235 | |
236 | Please have a look at the git commit logs to get a feel for what the norms | |
237 | are. | |
238 | ||
e99c37b4 PJ |
239 | Note that the commit message format follows git norms, so that “git log |
240 | –oneline” will have useful output. | |
fa482834 | 241 | |
e99c37b4 PJ |
242 | HACKING THE BUILD SYSTEM |
243 | ======================== | |
fa482834 PJ |
244 | |
245 | If you change or add to the build system (configure.ac, any Makefile.am, | |
246 | etc.), try to check that the following things still work: | |
247 | ||
e99c37b4 PJ |
248 | - make dist |
249 | ||
250 | - resulting dist tarball builds | |
251 | ||
252 | - out-of-tree builds | |
fa482834 PJ |
253 | |
254 | The quagga.net site relies on make dist to work to generate snapshots. It | |
255 | must work. Common problems are to forget to have some additional file | |
256 | included in the dist, or to have a make rule refer to a source file without | |
257 | using the srcdir variable. | |
258 | ||
e99c37b4 PJ |
259 | RELEASE PROCEDURE |
260 | ================= | |
261 | ||
262 | - Tag the appropriate commit with a release tag (follow existing | |
263 | conventions). | |
264 | ||
265 | [This enables recreating the release, and is just good CM practice.] | |
266 | ||
267 | - Create a fresh tar archive of the quagga.net repository, and do a | |
268 | test build: | |
fa482834 | 269 | |
e99c37b4 PJ |
270 | vim configure.ac |
271 | git commit -m "release: 0.99.99.99" | |
272 | git tag -u 54CD2E60 quagga-0.99.99.99 | |
273 | git push savannah tag quagga-0.99.99.99 | |
fa482834 | 274 | |
e99c37b4 PJ |
275 | git archive --prefix=quagga-release/ quagga-0.99.99.99 | tar xC /tmp |
276 | git log quagga-0.99.99.98..quagga-0.99.99.99 > \ | |
277 | /tmp/quagga-release/quagga-0.99.99.99.changelog.txt | |
278 | cd /tmp/quagga-release | |
fa482834 | 279 | |
e99c37b4 PJ |
280 | autoreconf -i |
281 | ./configure | |
282 | make | |
283 | make dist-gzip | |
fa482834 | 284 | |
e99c37b4 PJ |
285 | gunzip < quagga-0.99.99.99.tar.gz > quagga-0.99.99.99.tar |
286 | xz -6e < quagga-0.99.99.99.tar > quagga-0.99.99.99.tar.xz | |
287 | gpg -u 54CD2E60 -a --detach-sign quagga-0.99.99.99.tar | |
76a12162 | 288 | |
e99c37b4 PJ |
289 | scp quagga-0.99.99.99.* username@dl.sv.nongnu.org:/releases/quagga |
290 | ||
fa482834 | 291 | |
e99c37b4 PJ |
292 | Do NOT do this in a subdirectory of the Quagga sources, autoconf |
293 | will think it’s a sub-package and fail to include neccessary files. | |
76a12162 | 294 | |
e99c37b4 PJ |
295 | - Add the version number on https://bugzilla.quagga.net/, under |
296 | Administration, Products, “Quagga”, Edit versions, Add a version. | |
76a12162 | 297 | |
e99c37b4 PJ |
298 | - Edit the wiki on |
299 | https://wiki.quagga.net/wiki/index.php/Release\_status | |
76a12162 | 300 | |
e99c37b4 | 301 | - Post a news entry on Savannah |
76a12162 | 302 | |
e99c37b4 | 303 | - Send a mail to quagga-dev and quagga-users |
fa482834 | 304 | |
e99c37b4 PJ |
305 | The tarball which ‘make dist’ creates is the tarball to be released! The |
306 | git-archive step ensures you’re working with code corresponding to that in | |
fa482834 PJ |
307 | the official repository, and also carries out keyword expansion. If any |
308 | errors occur, move tags as needed and start over from the fresh checkouts. | |
309 | Do not append to tarballs, as this has produced non-standards-conforming | |
310 | tarballs in the past. | |
311 | ||
e99c37b4 | 312 | See also: <http://wiki.quagga.net/index.php/Main/Processes> |
fa482834 | 313 | |
e99c37b4 PJ |
314 | [TODO: collation of a list of deprecated commands. Possibly can be |
315 | scripted to extract from vtysh/vtysh\_cmd.c] | |
fa482834 | 316 | |
e99c37b4 PJ |
317 | TOOL VERSIONS |
318 | ============= | |
fa482834 PJ |
319 | |
320 | Require versions of support tools are listed in INSTALL.quagga.txt. | |
321 | Required versions should only be done with due deliberation, as it can | |
322 | cause environments to no longer be able to compile quagga. | |
323 | ||
e99c37b4 PJ |
324 | SHARED LIBRARY VERSIONING {#sec:dll-versioning} |
325 | ========================= | |
fa482834 | 326 | |
e99c37b4 | 327 | [this section is at the moment just gdt’s opinion] |
fa482834 | 328 | |
e99c37b4 | 329 | Quagga builds several shared libaries (lib/libzebra, ospfd/libospf, |
fa482834 PJ |
330 | ospfclient/libsopfapiclient). These may be used by external programs, |
331 | e.g. a new routing protocol that works with the zebra daemon, or | |
332 | ospfapi clients. The libtool info pages (node Versioning) explain | |
333 | when major and minor version numbers should be changed. These values | |
334 | are set in Makefile.am near the definition of the library. If you | |
335 | make a change that requires changing the shared library version, | |
336 | please update Makefile.am. | |
337 | ||
338 | libospf exports far more than it should, and is needed by ospfapi | |
339 | clients. Only bump libospf for changes to functions for which it is | |
340 | reasonable for a user of ospfapi to call, and please err on the side | |
341 | of not bumping. | |
342 | ||
343 | There is no support intended for installing part of zebra. The core | |
344 | library libzebra and the included daemons should always be built and | |
345 | installed together. | |
346 | ||
e99c37b4 PJ |
347 | GIT COMMIT SUBMISSION {#sec:git-submission} |
348 | ===================== | |
fa482834 PJ |
349 | |
350 | The preferred method for submitting changes is to provide git commits via a | |
21bbd111 | 351 | publicly-accessible git repository, which the maintainers can easily pull. |
fa482834 PJ |
352 | |
353 | The commits should be in a branch based off the Quagga.net master - a | |
e99c37b4 | 354 | “feature branch”. Ideally there should be no commits to this branch other |
fa482834 PJ |
355 | than those in master, and those intended to be submitted. However, merge |
356 | commits to this branch from the Quagga master are permitted, though strongly | |
357 | discouraged - use another (potentially local and throw-away) branch to test | |
358 | merge with the latest Quagga master. | |
359 | ||
360 | Recommended practice is to keep different logical sets of changes on | |
e99c37b4 PJ |
361 | separate branches - “topic” or “feature” branches. This allows you to still |
362 | merge them together to one branch (potentially local and/or “throw-away”) | |
fa482834 PJ |
363 | for testing or use, while retaining smaller, independent branches that are |
364 | easier to merge. | |
365 | ||
e99c37b4 | 366 | All content guidelines in section [sec:patch-submission], PATCH |
fa482834 PJ |
367 | SUBMISSION apply. |
368 | ||
e99c37b4 PJ |
369 | PATCH SUBMISSION {#sec:patch-submission} |
370 | ================ | |
fa482834 | 371 | |
e99c37b4 PJ |
372 | - For complex changes, contributors are strongly encouraged to first |
373 | start a design discussion on the quagga-dev list *before* starting | |
374 | any coding. | |
fa482834 | 375 | |
e99c37b4 PJ |
376 | - Send a clean diff against the ’master’ branch of the quagga.git |
377 | repository, in unified diff format, preferably with the ’-p’ | |
378 | argument to show C function affected by any chunk, and with the -w | |
379 | and -b arguments to minimise changes. E.g: | |
fa482834 | 380 | |
e99c37b4 | 381 | git diff -up mybranch..remotes/quagga.net/master |
fa482834 | 382 | |
e99c37b4 PJ |
383 | It is preferable to use git format-patch, and even more preferred to |
384 | publish a git repository (see GIT COMMIT SUBMISSION, section | |
385 | [sec:git-submission]). | |
fa482834 | 386 | |
e99c37b4 PJ |
387 | If not using git format-patch, Include the commit message in the |
388 | email. | |
fa482834 | 389 | |
e99c37b4 PJ |
390 | - After a commit, code should have comments explaining to the reviewer |
391 | why it is correct, without reference to history. The commit message | |
392 | should explain why the change is correct. | |
fa482834 | 393 | |
e99c37b4 | 394 | - Include NEWS entries as appropriate. |
fa482834 | 395 | |
e99c37b4 | 396 | - Include only one semantic change or group of changes per patch. |
fa482834 | 397 | |
e99c37b4 PJ |
398 | - Do not make gratuitous changes to whitespace. See the w and b |
399 | arguments to diff. | |
fa482834 | 400 | |
e99c37b4 PJ |
401 | - Changes should be arranged so that the least controversial and most |
402 | trivial are first, and the most complex or more controversial are | |
403 | last. This will maximise how many the Quagga maintainers can merge, | |
404 | even if some other commits need further work. | |
fa482834 | 405 | |
e99c37b4 PJ |
406 | - Providing a unit-test is strongly encouraged. Doing so will make it |
407 | much easier for maintainers to have confidence that they will be | |
408 | able to support your change. | |
fa482834 | 409 | |
e99c37b4 PJ |
410 | - New code should be arranged so that it easy to verify and test. E.g. |
411 | stateful logic should be separated out from functional logic as much | |
412 | as possible: wherever possible, move complex logic out to smaller | |
413 | helper functions which access no state other than their arguments. | |
fa482834 | 414 | |
e99c37b4 PJ |
415 | - State on which platforms and with what daemons the patch has been |
416 | tested. Understand that if the set of testing locations is small, | |
417 | and the patch might have unforeseen or hard to fix consequences that | |
418 | there may be a call for testers on quagga-dev, and that the patch | |
419 | may be blocked until test results appear. | |
fa482834 | 420 | |
e99c37b4 PJ |
421 | If there are no users for a platform on quagga-dev who are able and |
422 | willing to verify -current occasionally, that platform may be | |
423 | dropped from the “should be checked” list. | |
fa482834 | 424 | |
e99c37b4 PJ |
425 | PATCH APPLICATION |
426 | ================= | |
fa482834 | 427 | |
e99c37b4 | 428 | - Only apply patches that meet the submission guidelines. |
fa482834 | 429 | |
e99c37b4 PJ |
430 | - If the patch might break something, issue a call for testing on the |
431 | mailing-list. | |
fa482834 | 432 | |
e99c37b4 PJ |
433 | - Give an appropriate commit message (see above), and use the –author |
434 | argument to git-commit, if required, to ensure proper attribution | |
435 | (you should still be listed as committer) | |
fa482834 | 436 | |
e99c37b4 PJ |
437 | - Immediately after commiting, double-check (with git-log and/or |
438 | gitk). If there’s a small mistake you can easily fix it with ‘git | |
439 | commit –amend ..’ | |
fa482834 | 440 | |
e99c37b4 PJ |
441 | - When merging a branch, always use an explicit merge commit. Giving |
442 | –no-ff ensures a merge commit is created which documents “this human | |
443 | decided to merge this branch at this time”. | |
fa482834 | 444 | |
e99c37b4 PJ |
445 | STABLE PLATFORMS AND DAEMONS |
446 | ============================ | |
fa482834 PJ |
447 | |
448 | The list of platforms that should be tested follow. This is a list | |
449 | derived from what quagga is thought to run on and for which | |
450 | maintainers can test or there are people on quagga-dev who are able | |
451 | and willing to verify that -current does or does not work correctly. | |
452 | ||
e99c37b4 PJ |
453 | - BSD (Free, Net or Open, any platform) |
454 | ||
455 | - GNU/Linux (any distribution, i386) | |
456 | ||
457 | - Solaris (strict alignment, any platform) | |
458 | ||
459 | - future: NetBSD/sparc64 | |
fa482834 PJ |
460 | |
461 | The list of daemons that are thought to be stable and that should be | |
462 | tested are: | |
463 | ||
e99c37b4 PJ |
464 | - zebra |
465 | ||
466 | - bgpd | |
467 | ||
468 | - ripd | |
469 | ||
470 | - ospfd | |
471 | ||
472 | - ripngd | |
473 | ||
fa482834 PJ |
474 | Daemons which are in a testing phase are |
475 | ||
e99c37b4 | 476 | - ospf6d |
fa482834 | 477 | |
e99c37b4 PJ |
478 | - isisd |
479 | ||
480 | - watchquagga | |
481 | ||
482 | IMPORT OR UPDATE VENDOR SPECIFIC ROUTING PROTOCOLS | |
483 | ================================================== | |
fa482834 PJ |
484 | |
485 | The source code of Quagga is based on two vendors: | |
486 | ||
e99c37b4 PJ |
487 | `zebra_org` (<http://www.zebra.org/>) `isisd_sf` |
488 | (<http://isisd.sf.net/>) | |
fa482834 PJ |
489 | |
490 | To import code from further sources, e.g. for archival purposes without | |
e99c37b4 PJ |
491 | necessarily having to review and/or fix some changeset, create a branch |
492 | from ‘master’: | |
fa482834 | 493 | |
e99c37b4 PJ |
494 | git checkout -b archive/foo master |
495 | <apply changes> | |
496 | git commit -a "Joe Bar <joe@example.com>" | |
497 | git push quagga archive/foo | |
fa482834 | 498 | |
e99c37b4 | 499 | presuming ‘quagga’ corresponds to a file in your .git/remotes with |
fa482834 | 500 | configuration for the appropriate Quagga.net repository. |