From 710e7eb50e631f6f2ff98cce7a18b8f82e153f65 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 13 Apr 2003 11:29:28 +0000 Subject: add a few notes about how to deal with CVS COMMIT access --- COMMIT_NOTES | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 COMMIT_NOTES (limited to 'COMMIT_NOTES') diff --git a/COMMIT_NOTES b/COMMIT_NOTES new file mode 100644 index 00000000..e8b9e46f --- /dev/null +++ b/COMMIT_NOTES @@ -0,0 +1,24 @@ +A quick list of rules for committing stuff into netfilter cvs: + +- Always include the Name of the Author/Contributor in the CVS comment + like 'fix for foo (Au Thor)' + +- make sure that you have set the executable bits on an 'extensions/.*-test' + script before adding/committing it to CVS + +- If the commit fixes a bugzilla bug, please include '(Closes: #bugnr)' in + the commit message + +- Make sure you don't commit to CVS while a feature freeze is announced + +- For new extensions, there are two possible cases: + 1) header files are just in patch-o-matic patch, you need an + 'extensions/.*-test' script to have a conditional build + 2) header files are in patch-o-matic patch, and copied to + 'netfilter/include/linux/netfilter_xxx'. This way the extension + can be built _unconditionally_, and thus be included in + 'extensions/Makefile'. Make sure to keep the headers in sync! + + Usually '1)' is used, but in case something is expected to show up in the + kernel soon, we should already make userspace support unconditionally. + -- cgit v1.2.3