| 1 |
|
| 2 |
CVS checkin process: |
| 3 |
|
| 4 |
1) All checkins should include a log message. Included in the log |
| 5 |
message should be what changed (files), why it changed (what new |
| 6 |
feature or bug was fixed), as well as the date and time (while CVS |
| 7 |
does stamp these automatically, it can be easier to read the log for |
| 8 |
that information than looking at the CVS header). |
| 9 |
|
| 10 |
It is not necessary to go into a long exposition, and pasting the actual |
| 11 |
changes is not generally useful. But this log message should be useful for |
| 12 |
someone looking over the logs at a future point to see what did change. |
| 13 |
Having a log like 'various skill stuff' isn't very useful. A log message like |
| 14 |
'prevent abuse with the literacy skill, and increase chance of singing' is |
| 15 |
much more useful, and not a lot more words. |
| 16 |
|
| 17 |
One of the main uses of the log entries is when bugs are reported where |
| 18 |
behaviour changed between version X and Y to be able to look at the log |
| 19 |
entries and get an idea of what specific revision may have caused that |
| 20 |
change. |
| 21 |
|
| 22 |
If doing a commit of several different files at each time, and the commits |
| 23 |
are different in nature, do try to at least mention what is changing in |
| 24 |
each file. |
| 25 |
|
| 26 |
Do not refer to other files or other log messages. Saying 'see changes |
| 27 |
file' is not useful, nor is a message like 'continuing with last set |
| 28 |
of commits'. Such messages are not useful when trying to look back through |
| 29 |
the logs at a future point. |
| 30 |
|
| 31 |
There is no excuse for not having a good log entry. Worst case, cut and |
| 32 |
past from the CHANGES file or those prior commits. My typical method |
| 33 |
of doing commits is filling out the CHANGES file, and then |
| 34 |
copying/pasting from that when I do the commit. |
| 35 |
|
| 36 |
Please also update the CHANGES file for the appropriate distribution - |
| 37 |
this is very useful to look through to get an idea of everything that |
| 38 |
has changed since some release. Very minor things (eg, fixing typos, |
| 39 |
or other things that don't actually effect how the program runs) do not |
| 40 |
need to be in the CHANGES file. |
| 41 |
|
| 42 |
2) All checkins should go through at least minimum testing: |
| 43 |
For source code, this means it compiles and at least a basic test has |
| 44 |
been done (for example, if it is a new spell, have you tried casting |
| 45 |
the spell?) This basic testing implies the code at least compiles |
| 46 |
also. I realize it is very difficult to do 100% testing of code, but |
| 47 |
at least a basic test should be done. |
| 48 |
|
| 49 |
All source code should also be ANSI & POSIX compliant. Don't use // for |
| 50 |
comments. Be careful of new library calls that are not being used |
| 51 |
elsewhere in the source - there may be a reason they are not being used. |
| 52 |
"it compiles on my system" is not justification for writing code that does |
| 53 |
not work elsewhere. It is understandable that you may not know that the |
| 54 |
code written is non portable, but once this is learned, it should be |
| 55 |
corrected. |
| 56 |
|
| 57 |
For archetypes, this testing should involve rebuilding the arch file and |
| 58 |
running with the new file. There should be no errors in the loading |
| 59 |
of the archetype files. |
| 60 |
|
| 61 |
For maps, this means that the map should load, and the exits should lead |
| 62 |
back and forth. Note that maps in the unlinked directory are more |
| 63 |
work in progress so can be checked in a more experimental state. |
| 64 |
|
| 65 |
3) Style & Balance: Your changes may work, but do they fit in with the |
| 66 |
rest of the game. This basically means following the files guides |
| 67 |
that already existing, eg doc/programming_guide, doc/mapguide |
| 68 |
|
| 69 |
There really is no arch guide, but take common sense. Does the |
| 70 |
object fit in with the game (ie, a blaster rifle would not), is this |
| 71 |
arch very unbalancing, etc. |
| 72 |
|
| 73 |
4) Before starting a big project, send a note to the mailing list asking |
| 74 |
for opinions. While it is not possible to prevent someone working on |
| 75 |
whatever they may want, if the general consensus is that it is a bad idea, |
| 76 |
you may want to find that out before spending a lot of work on it only |
| 77 |
to find out that your idea will not get added to the game. |
| 78 |
|
| 79 |
5) Take responsibility for your code. If you check in something and a bug |
| 80 |
is reported in it, go an fix it. |
| 81 |
|
| 82 |
6) Look at the testplans, and if your code may benefit from them, use them. |
| 83 |
Likewise, if you develope a testplan for your code, record it in the |
| 84 |
testplan directory. |
| 85 |
|
| 86 |
Mark Wedel |
| 87 |
May 12, 2001 |
