[CF-Devel] CVS access/commiters note

[dnh]

Cmpletely agree and accept this email,

dnh

On Sat, 12 May 2001, Mark Wedel wrote:

>
     
     
     >
     
      With the upcoming release of 1.0, and the fact that currently the
     
     >
     
      following rules are not always being followed, I decided to write a more
     
     >
     
      formal description for doing CVS checkins.
     
     >
     
     
     >
     
       If you have additions or other notes, feel free to followup.
     
     >
     
     
     >
     
      1) Log messages should include the following:
     
     >
     
         a) what changed
     
     >
     
         b) why it changed
     
     >
     
         c) name of person doing the checkin, and date done.
     
     >
     
     
     >
     
      It is not necessary to go into a long exposition, and pasting the actual
     
     >
     
      changes is not generally useful.  But this log message should be useful for
     
     >
     
      someone looking over the logs at a future point to see what did change.
     
     >
     
      Havinga log like 'various skill stuff' isn't very useful.  A log message like
     
     >
     
      'prevent abuse with the literacy skill, and increase chance of singing' is
     
     >
     
      much more useful, and not a lot more words.
     
     >
     
     
     >
     
      One of the main uses of the log entries is when bugs are reported where
     
     >
     
      behaviour changed between version X and Y to be able to look at the log
     
     >
     
      entries and get an idea of what specific revision may have caused that
     
     >
     
      change.
     
     >
     
     
     >
     
      If doing a commit of several different files at each time, and the commits
     
     >
     
      are different in nature, do try to at least mention what is changing in
     
     >
     
      each file.
     
     >
     
     
     >
     
      Do not refer to other files or other log messages.  Saying 'see changes
     
     >
     
      file' is not useful, nor is a message like 'continuing with last set
     
     >
     
      of commits'.  Such messages are not useful when trying to look back through
     
     >
     
      the logs at a future point.
     
     >
     
     
     >
     
      There is no excuse for not having a good log entry.  Worst case, cut and
     
     >
     
      past from the CHANGES file or those prior commits.  My typical method
     
     >
     
      of doing commits is filling out the CHANGES file, and then
     
     >
     
      copying/pasting from that when I do the commit.
     
     >
     
     
     >
     
      2) All checkins should go through at least minimum testing:
     
     >
     
         For source code, this means it compiles and at least a basic test has
     
     >
     
         been done (for example, if it is a new spell, have you tried casting
     
     >
     
         the spell?)  This basic testing implies the code at least compiles
     
     >
     
         also.  I realize it is very difficult to do 100% testing of code, but
     
     >
     
         at least a basic test should be done.  
     
     >
     
     
     >
     
         All source code should also be ANSI & POSIX compliant.  Don't use // for
     
     >
     
         comments.  Be careful of new library calls that are not being used
     
     >
     
         elsewhere in the source - there may be a reason they are not being used.
     
     >
     
         "it compiles on my system" is not justification for writing code that does
     
     >
     
         not work elsewhere.  It is understandable that you may not know that the
     
     >
     
         code written is non portable, but once this is learned, it should be
     
     >
     
         corrected.
     
     >
     
     
     >
     
         For archetypes, this testing should involve rebuilding the arch file and
     
     >
     
         running with the new file.  There should be no errors in the loading
     
     >
     
         of the archetype files.
     
     >
     
     
     >
     
         For maps, this means that the map should load, and the exits should lead
     
     >
     
         back and forth.  Note that maps in the unlinked directory are more
     
     >
     
         work in progress so can be checked in a more experimental state.
     
     >
     
     
     >
     
      3) Style & Balance: Your changes may work, but do they fit in with the
     
     >
     
         rest of the game.  This basically means following the files guides
     
     >
     
         that already existing, eg doc/programming_guide, doc/mapguide
     
     >
     
     
     >
     
         There really is no arch guide, but take common sense.  Does the
     
     >
     
         object fit in with the game (ie, a blaster rifle would not), is this
     
     >
     
         arch very unbalancing, etc.
     
     >
     
     
     >
     
      4) Before starting a big project, send a note to the mailing list asking
     
     >
     
         for opinions.  While it is not possible to prevent someone working on
     
     >
     
         whatever they may want, if the general consensus is that it is a bad idea, 
     
     >
     
         you may want to find that out before spending a lot of work on it only
     
     >
     
         to find out that your idea will not get added to the game.
     
     >
     
     
     >
     
      Mark Wedel
     
     >
     
      May 12, 2001
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >