diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-06 00:55:53 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-06 00:55:53 +0000 |
commit | 3d0386f27ca66379acf50199e1d1298386eeeeb8 (patch) | |
tree | f87bd4a126b3a843858eb447e8fd5893c3ee3882 /tests/deckard/contrib/libfaketime/README.developers | |
parent | Initial commit. (diff) | |
download | knot-resolver-3d0386f27ca66379acf50199e1d1298386eeeeb8.tar.xz knot-resolver-3d0386f27ca66379acf50199e1d1298386eeeeb8.zip |
Adding upstream version 3.2.1.upstream/3.2.1upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'tests/deckard/contrib/libfaketime/README.developers')
-rw-r--r-- | tests/deckard/contrib/libfaketime/README.developers | 106 |
1 files changed, 106 insertions, 0 deletions
diff --git a/tests/deckard/contrib/libfaketime/README.developers b/tests/deckard/contrib/libfaketime/README.developers new file mode 100644 index 0000000..b8df57f --- /dev/null +++ b/tests/deckard/contrib/libfaketime/README.developers @@ -0,0 +1,106 @@ +This file contains information for libfaketime developers and contributors. + + +GENERAL +======= + +Starting with libfaketime v0.9.5, development and issue handling is +completely done via Github: + + https://github.com/wolfcw/libfaketime + +- Official releases are tagged. +- Code contributions and bugfixes are merged into the "development" branch, + which is considered unstable and may contain code that is not yet fully + tested. +- The "master" branch is updated with tested code only; it is ensured that + it compiles and works cleanly at least on current Linux and OS X systems. + +Code contributions are highly welcome, preferably via pull requests on Github. + + +CODE STYLE +========== + +Please try to stick to the following code formatting style guidelines: + +- No tabs, only spaces for indentation. +- Avoid trailing whitespace. +- Indentation is 2 spaces for each level. +- Opening and closing curly brackets have to be on lines of their own. +- Use under_score_names for function and variable names; avoid using camelCase. +- // and /*...*/ style comments may and shall be used. + +Example: + +/* This function will do nothing */ +void do_nothing(int how_often) +{ + int counter; + for (counter = 0; counter < how_often; counter++) + { + counter = counter; // our do-nothing algorithm + } +} + +- Use -DDEBUG and #ifdef DEBUG for development and testing. Avoid printing + to stdout or stderr outside "#ifdef DEBUG"; if it is necessary to inform + the user a run-time, prefix your output with "faketime" or make otherwise + sure that the user knows where the message is coming from. + +- If you add new functions to libfaketime.c, try placing them somewhere + where they fit will: Usually, functions are grouped by functionality + (e.g., all functions related to faking file timestamps). If that's not + possible, group them by contributor, or document your placement strategy + in the commit message. + + +DEVELOPMENT, BUILDING, AND TESTING +================================== + +- Don't break existing behaviour. Backward compatibility matters (unless + the modification fixes bugs :-)). + +- Add tests for new features. Extend test/timetest.c appropriately and + try to use the functional testing framework wherever possible. + +- Compiler and linker warnings are treated as errors and not acceptable. + +- If you cannot test the code on both Linux and OS X yourself, please + let us know and consider wrapping your code in #ifdef / #ifndef __APPLE__ + statements. + + +DOCUMENTATION +============= + +For anything more than small bugfixes, please update the user documentation +and credits appropriately: + +- The NEWS file should mention the change and your credits. +- The README and README.OSX files should be updated whenever functionality + is added or modified. +- The manpage man/faketime.1 should be updated when the wrapper application + is modified. + +For credits, please either mention your real name, your Github username, or +your email address. + +In your own interest, please be verbose on user documentation and comments +in the source code. Users will not know about new features unless they are +documented. Other authors and maintainers will need to understand your code +easily. + + +RELEASES +======== + +Official new releases are created whenever a significant amount of changes +(bugfixes or new functionality) has piled up; on average, there is one new +official release per year. Users who need to stick to the bleeding edge +are supposed to use the current state of the "master" branch at any time. + +libfaketime maintainers for several Linux distributions are informed about +release candidates and new releases by email. Contact wolfcw on Github if +you are interested in receiving notifications, or use Github functionality +to get informed about updates. |