| gdt | d9fd04c | 2003-12-19 19:20:25 +0000 | [diff] [blame] | 1 | -*- mode: text; -*- |
| 2 | |
| 3 | $Id: HACKING,v 1.1 2003/12/19 19:20:25 gdt Exp $ |
| 4 | |
| 5 | GUIDELINES FOR HACKING ON QUAGGA |
| 6 | |
| 7 | [this is a strawman on which consensus has been neither tested nor reached] |
| 8 | |
| 9 | [this is a draft in progress] |
| 10 | |
| 11 | Generally, GNU coding standards apply. The indentation style is a bit |
| 12 | different from standard GNU style, and the existing style should be |
| 13 | maintained and used for new code. |
| 14 | |
| 15 | PATCH SUBMISSION |
| 16 | |
| 17 | * Send a clean diff against the head of CVS. |
| 18 | |
| 19 | * Include ChangeLog and NEWS entries as appropriate before the patch |
| 20 | (or in it if you are 100% up to date). |
| 21 | |
| 22 | * Inclue only one semantic change or group of changes per patch.p |
| 23 | |
| 24 | * Do not make gratuitous changes to whitespace. |
| 25 | |
| 26 | * State on which platforms and with what daemons the patch has been |
| 27 | tested. Understand that if the set of testing locations is small, |
| 28 | and the patch might have unforeseen or hard to fix consequences that |
| 29 | there may be a call for testers on quagga-dev, and that the patch |
| 30 | may be blocked until test results appear. |
| 31 | |
| 32 | If there are no users for a platform on quagga-dev who are able and |
| 33 | willing to verify -current occasionally, that platform may be |
| 34 | dropped from the "should be checked" list. |
| 35 | |
| 36 | PATCH APPLICATION TO CVS |
| 37 | |
| 38 | * Only apply patches that meet the submission guidelines. |
| 39 | |
| 40 | * If a patch is large (perhaps more than 100 new/changed lines), tag |
| 41 | the repository before and after the change with e.g. before-foo-fix |
| 42 | and after-foo-fix. |
| 43 | |
| 44 | * If the patch might break something, issue a call for testing on the |
| 45 | mailinglist. |
| 46 | |
| 47 | * By committing a patch, you are responsible for fixing problems |
| 48 | resulting from it (or backing it out). |
| 49 | |
| 50 | STABLE PLATFORMS AND DAEMONS |
| 51 | |
| 52 | The list of platforms that should be tested follow. This is a list |
| 53 | derived from what quagga is thought to run on and for which |
| 54 | maintainers can test or there are people on quagga-dev who are able |
| 55 | and willing to verify that -current does or does not work correctly. |
| 56 | |
| 57 | BSD (Free, Net or Open, any platform) # without capabilities |
| 58 | GNU/Linux (any distribution, i386) |
| 59 | [future: some 64-bit machine, e.g. NetBSD/sparc64] |
| 60 | [Solaris? (could address 64-bit issue)] |
| 61 | |
| 62 | The list of daemons that are thought to be stable and that should be |
| 63 | tested are: |
| 64 | |
| 65 | zebra |
| 66 | bgpd |
| 67 | ripd |
| 68 | ospfd |
| 69 | ripngd |