proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-08-08 14:34:22 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

2005-11-10 Paul Jakma <paul.jakma@sun.com>

Browse Source 
* HACKING: Add recommendation to provide a single Subject
	  style description to the commit message.
	  Add some recommendations for ChangeLog.
This commit is contained in:
paul 2005-11-10 10:21:19 +00:00
parent 5729e089d9
commit ca6383ba74
2 changed files with 57 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ChangeLog
View File

@ -1,3 +1,9 @@
2005-11-10 Paul Jakma <paul.jakma@sun.com>
* HACKING: Add recommendation to provide a single Subject
style description to the commit message.
Add some recommendations for ChangeLog.
2005-09-29 Paul Jakma <paul.jakma@sun.com> 2005-09-29 Paul Jakma <paul.jakma@sun.com>
* configure.ac: Add the test for Solaris least-privileges. Set * configure.ac: Add the test for Solaris least-privileges. Set

62
HACKING
View File

@ -1,5 +1,5 @@
-*- mode: text; -*- -*- mode: text; -*-
$Id: HACKING,v 1.20 2005/04/25 00:37:03 paul Exp $ $Id: HACKING,v 1.21 2005/11/10 10:21:19 paul Exp $
GUIDELINES FOR HACKING ON QUAGGA GUIDELINES FOR HACKING ON QUAGGA
@ -87,11 +87,37 @@ structural changes should also be mentioned in the top-level
ChangeLog. ChangeLog.
Certain directories do not contain project code, but contain project Certain directories do not contain project code, but contain project
meta-data, eg packaging information, changes to files in these directory may meta-data, eg packaging information, changes to files in these
not require the global ChangeLog to be updated (at the discretion of the directory may not require the global ChangeLog to be updated (at the
maintainer who usually maintains that meta-data). Also, CVS meta-data such discretion of the maintainer who usually maintains that meta-data).
as cvsignore files do not require ChangeLog updates, just a sane commit Also, CVS meta-data such as cvsignore files do not require ChangeLog
message. updates, just a sane commit message.
The ChangeLog should provide:
* The date, in YYYY-MM-DD format
* The author's name and email.
* a short description of each change made
* file by file
* function by function (use of "ditto" is allowed)
(detailed discussion of non-obvious reasoning behind and/or
implications of a change should be made in comments in the code
concerned). The changelog optionally may have a (general) description,
to provide a short description of the general intent of the patch. The
reason for such itemised ChangeLogs is to encourage the author to
self-review every line of the patch, as well as provide reviewers an
index of which changes are intended, along with a short description for
each. E.g.:
2012-05-29 Joe Bar <joe@example.com>
* (general) Add a new DOWN state to the frob state machine
to allow the barinator to detect loss of frob.
* frob.h: (struct frob) Add DOWN state flag.
* frob.c: (frob_change) set/clear DOWN appropriately on state
change.
* bar.c: (barinate) Check frob for DOWN state.
HACKING THE BUILD SYSTEM HACKING THE BUILD SYSTEM
@ -196,11 +222,25 @@ PATCH APPLICATION TO CVS
* If the patch might break something, issue a call for testing on the * If the patch might break something, issue a call for testing on the
mailinglist. mailinglist.
* Give an appropriate commit message, eg the ChangeLog entry should suffice, * Give an appropriate commit message, prefixed with a category name
if it does not, then the ChangeLog entry itself needs to be corrected. The (either the name of the daemon, the library component or the general
commit message text should be identical to that added to the ChangeLog topic) and a one-line short summary of the change as the first line,
message. (One suggestion: when commiting, use your editor to read in the suitable for use as a Subject in an email. The ChangeLog entry should
ChangeLog and delete all previous ChangeLogs.) suffice as the body of the commit message, if it does not, then the
ChangeLog entry itself needs to be corrected. The commit message text
should be identical to that added to the ChangeLog message. (One
suggestion: when commiting, use your editor to read in the ChangeLog
and delete all previous ChangeLogs.) An example:
----------------------------------------------------------------
[frob] Defangulator needs to specify frob
2012-05-12 Joe Bar <joe@example.com>
* frobinate.c: (frob_lookup) fix NULL dereference
(defangulate) check whether frob is in state FROB_VALID
before defangulating.
----------------------------------------------------------------
* By committing a patch, you are responsible for fixing problems * By committing a patch, you are responsible for fixing problems
resulting from it (or backing it out). resulting from it (or backing it out).