[CF-Devel] About CVS server stability.

[Mark Wedel]

 I've enclosed the CVS checking doc at the end of this message.

 but it seems to me the issue of the discussion has gotten a bit off track from
the start.

 From the guide at the end, the developer is supposed to do testing before
checkin.  This of course does not mean bug free (ideally yes, but realistically
no).

 As I've said previously, you can do cvs checkouts at an arbitrary date.  So if
someone wants to checkout CVS as it was before AV's patch, they just need to do
a cvs checkout -d 02/27/2002 (or whatever).

 As a note, I think the main CVS branch should be the one with the new
features.  The guidelines for CVS checkins should be followed.

 The main issue in this case seems to be the desire to be able to be able to
apply possible future patches without this piece of the code.  Of course, there
may be no new patches done until after this becomes stable - who knows.  but I
think if that is the case, then perhaps the easiest thing is to just keep a
patch archive of all bugfixes done past this release, and the people that need
the stable release can apply that patch archive.  When its fairly clear that
this modification is 'safe', then people jsut re-base to the CVS at that point.

 Of course, the patches would also go in CVS.  The problem with this approach is
keeping this extra patch file.  The bigger question is how many people will
actually use this - if only one or two servers care about this, then probably
those server admins should be the ones that take responsiblity for this.

 


CVS checkin process:

1) All checkins should include a log message.  Included in the log
   message should be what changed (files), why it changed (what new
   feature or bug was fixed), as well as the date and time (while CVS
   does stamp these automatically, it can be easier to read the log for
   that information than looking at the CVS header).

   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.
   Having a 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.

   Please also update the CHANGES file for the appropriate distribution -
   this is very useful to look through to get an idea of everything that
   has changed since some release.  Very minor things (eg, fixing typos,
   or other things that don't actually effect how the program runs) do not
   need to be in the CHANGES file.

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.

5) Take responsibility for your code.  If you check in something and a bug
   is reported in it, go an fix it. 

6) Look at the testplans, and if your code may benefit from them, use them.
   Likewise, if you develope a testplan for your code, record it in the
   testplan directory.

Mark Wedel
May 12, 2001