| 1 |
root |
1.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 |
