123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151 |
- -*- mode: text; -*-
- $Id: HACKING,v 1.7 2004/07/23 16:23:56 gdt Exp $
- GUIDELINES FOR HACKING ON QUAGGA
- [this is a draft in progress]
- Generally, GNU coding standards apply. The indentation style is a bit
- different from standard GNU style, and the existing style should be
- maintained and used for new code.
- Be particularly careful not to break platforms/protocols that you
- cannot test.
- New code should have good comments, and changes to existing code
- should in many cases upgrade the comments when necessary for a
- reviewer to conclude that the change has no unintended consequences.
- CHANGELOG
- Add a ChangeLog entry whenever changing code, except for minor fixes
- to a commit (with a ChangeLog entry) within the last few days.
- There is at present a mixed style for ChangeLog, with some changes
- being described in per-directory ChangeLog files, and some at top
- level.
- [TBD: resolve per-dir vs top-level, perhaps by reading GNU coding
- standards]
- SHARED LIBRARY VERSIONING
- [this section is at the moment just gdt's opinion]
- Quagga builds several shared libaries (lib/libzebra, ospfd/libospf,
- ospfclient/libsopfapiclient). These may be used by external programs,
- e.g. a new routing protocol that works with the zebra daemon, or
- ospfapi clients. The libtool info pages (node Versioning) explain
- when major and minor version numbers should be changed. These values
- are set in Makefile.am near the definition of the library. If you
- make a change that requires changing the shared library version,
- please update Makefile.am.
- libospf exports far more than it should, and is needed by ospfapi
- clients. Only bump libospf for changes to functions for which it is
- reasonable for a user of ospfapi to call, and please err on the side
- of not bumping.
- There is no support intended for installing part of zebra. The core
- library libzebra and the included daemons should always be built and
- installed together.
- PATCH SUBMISSION
- * Send a clean diff against the head of CVS in unified diff format, eg by:
- cvs <cvs opts> diff -uwb ....
- * Include ChangeLog and NEWS entries as appropriate before the patch
- (or in it if you are 100% up to date).
- * Inclue only one semantic change or group of changes per patch.p
- * Do not make gratuitous changes to whitespace. See the w and b arguments
- to diff.
- * State on which platforms and with what daemons the patch has been
- tested. Understand that if the set of testing locations is small,
- and the patch might have unforeseen or hard to fix consequences that
- there may be a call for testers on quagga-dev, and that the patch
- may be blocked until test results appear.
- If there are no users for a platform on quagga-dev who are able and
- willing to verify -current occasionally, that platform may be
- dropped from the "should be checked" list.
- PATCH APPLICATION TO CVS
- * Only apply patches that meet the submission guidelines.
- * If a patch is large (perhaps more than 100 new/changed lines), tag
- the repository before and after the change with e.g. before-foo-fix
- and after-foo-fix.
- * If the patch might break something, issue a call for testing on the
- mailinglist.
- * Give an appropriate commit message, eg the ChangeLog entry should suffice,
- if it does not, then the ChangeLog entry itself needs to be corrected.
- * By committing a patch, you are responsible for fixing problems
- resulting from it (or backing it out).
- STABLE PLATFORMS AND DAEMONS
- The list of platforms that should be tested follow. This is a list
- derived from what quagga is thought to run on and for which
- maintainers can test or there are people on quagga-dev who are able
- and willing to verify that -current does or does not work correctly.
- BSD (Free, Net or Open, any platform) # without capabilities
- GNU/Linux (any distribution, i386)
- [future: some 64-bit machine, e.g. NetBSD/sparc64]
- [Solaris? (could address 64-bit issue)]
- The list of daemons that are thought to be stable and that should be
- tested are:
- zebra
- bgpd
- ripd
- ospfd
- ripngd
- IMPORT OR UPDATE VENDOR SPECIFIC ROUTING PROTOCOLS
- The source code of Quagga is based on two vendors:
- zebra_org (http://www.zebra.org/)
- isisd_sf (http://isisd.sf.net/)
- In order to import source code, the following procedure should be used:
- * Tag the Current Quagga CVS repository:
- cvs tag import_isisd_sf_20031223
- * Import the source code into the Quagga's framework. You must not modified
- this source code. It will be merged later.
- cd dir_isisd
- export CVSROOT=:pserver:LOGIN@anoncvs.quagga.net:/var/cvsroot
- cvs import quagga/isisd isisd_sf isisd_sf_20031223
- ---COMMENTS---
- Vendor: [isisd_sf] Sampo's ISISd from Sourceforge
- Tag: [isisd_sf_20031217] Current CVS release
- ---
- * Update your Quagga's directory:
- cd dir_quagga
- cvs update -dP
- or
- cvs co -d quagga_isisd quagga
- * Merge the code, then commit:
- cvs commit
|