From f6ef5cff1bec287bb3d5e8e97d12dde882ace71c Mon Sep 17 00:00:00 2001 From: Yamagi Burmeister Date: Sat, 3 Dec 2016 09:23:13 +0100 Subject: [PATCH] Reformat the CONTRIBUTE file --- CONTRIBUTE | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/CONTRIBUTE b/CONTRIBUTE index f54f38c0..afe7d959 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -11,33 +11,33 @@ At this time there're no open tasks regaring Quake II. Nevertheless the hints for working with the code: -- Sign up for a Github account and fork our yquake2 repository. This allows - the easy integration of upstream changes into your branch and sending of - pull requests. You'll get a wiki and a bugtracker for free. -- To contribute your changes back into the main project send pull requests - via Github. It's much easier to review and merge pull requests than patches. +- Sign up for a Github account and fork our yquake2 repository. This allows the + easy integration of upstream changes into your branch and sending of pull + requests. You'll get a wiki and a bugtracker for free. +- To contribute your changes back into the main project send pull requests via + Github. It's much easier to review and merge pull requests than patches. Please send only pull reqeuests from a distinct branch at not from your "master" branch! - Quake II has a very fragile and broken codebase. Even after years of cleanup it's still a disaster. Therefore: - Do only one change at a time! - Test after each change (play at least through base1.bsp) - - Commit early and commit often to create a fine grained history. - This helps "git bisect" to find bugs and errors. + - Commit early and commit often to create a fine grained history. This helps + "git bisect" to find bugs and errors. - Do not try to clean up things or even rewrite code that you do not - understand to 110%! Even small behavioral changes can introduce - gameplay changes and trigger new bugs! Especially everything that - depends on map data (e.g. path finding or collision detection) is - very likely to break in interesting ways! + understand to 110%! Even small behavioral changes can introduce gameplay + changes and trigger new bugs! Especially everything that depends on map data + (e.g. path finding or collision detection) is very likely to break in + interesting ways! - Do not add new dependencies. If you must add a new one contact the Yamagi - Quake II developers prior to it! Everything that adds dependencies should - be hided behint preprocessor macros. + Quake II developers prior to it! Everything that adds dependencies should be + hided behint preprocessor macros. - If your changes change the gameplay experience, make them optional by introducing a new cvar. - Linux is not the only operating system out there. All changes should be - portable to other platform (writing pure ANSI-C or C99 is recommended but - not always applicable). -- x86 ist not the only CPU architecture. All changes should be done in pure - C (e.g. no inline assembler) and in an endianess independed way. + portable to other platform (writing pure ANSI-C or C99 is recommended but not + always applicable). +- x86 ist not the only CPU architecture. All changes should be done in pure C + (e.g. no inline assembler) and in an endianess independed way. - gcc is not the only compiler. Test your changes with clang.