[7] RE: [CF-Devel] Starting Suspended Animation Process

[Mark Wedel]

 My personal thoughts on this:

First, for better or worse, the #crossfire irc channel has become a place where
lots of discussion is going on.  This is good in many cases when bouncing ideas
of people or discussing certain ideas.  The problem here is that if you are not
online at irc when the discussion happens, the first you hear about it is when
it gets checked it.  So the best thing is to still use irc as a discussion place
(which can be useful to get a reading on how much desire there is in what you
plan to work on), but still follow up to the list, perhaps something of the
lines of 'from the irc discussion, this is what I'm thinking of doing'. 
Unfortunately, it is hard to remember to do that at times if you have had a
discussion and think the idea is widely accepted (Because the people on irc when
you were there said cool idea).   But it really should be done - it is also nice
in that the mailing lists are archived, so even if an idea does not lead to
anything, you can then say 'look back at the old mailing archive for reasons
that wasn't done'.

 Second, while multiple cvs branches (stable vs unstable) may seem to help, it
only really does if people actually do run the unstable branches.  From my brief
experience, dealing with multiple branches in CVS, while not really difficult,
does consume a fair amount of extra time.  I actually don't see anything
specific about what should and should not get put into CVS in the doc
directory.  The spoken rule is that the functionality needs to have been tested,
but saying 'tested' is fairly broad (trying to figure out all the interactions
your code has with other code.  There are no testsuites in crossfire, so its not
like you can just go and run a regression test and see if anything breaks.

 I should also note a few other things about the CVS repository - first, it is
up to each server if they decide to run the latest CVS.  I will say that all the
servers that did that for the 1.0 release were a great help in finding many
bugs.  How good an idea it is to do that all the time for a widely used server
has just been shown that it may not be a good idea.  For people running widely
public servers, they may want to hold of a few days/week before updating after
big changes just to insulate themselves - hopefully people running CVS on
personal server will find any terrible bugs in that time period.  Second, CVS
does allow you to use dates (-B some date) when doing updates and checkouts, so
it is generally very easy to go back to an earlier release.

 Now certainly, I will admit it has been an unusually long time since the last
official release.  It may be worthwhile to take what was in the server as of a
few days ago and use that as a 1.1.0 release.  But from my standpoint, it gets
to be a tricky thing - ideally, for stability, you want to make the release
before any big changes go in (so the code released has been tested and debugged
for a while).  The obviously problem with that approach is then fairly shortly
thereafter, when people ask about some cool feature, you then say 'thats in
CVS'.  I will also admit that releases have slowed down a bit since CVS became
widespread, because it became easier to say 'thats in CVS'.

 Perhaps some formal release schedule may be used, eg, at the end of every third
quarter, an official release is mode.  For months 1 and 2 of that quarter,
normal rapid development/checkin can be done, but in the third month (eg, march
01 through march 31, june 01 through june 31, etc), only bug fixes get checked
in?  Maybe starting around the second week of that month, the public servers may
want to start keeping up to date with CVS to better test and find bugs.  But
certainly in that 2 month period of rapid development, they really should not.

 This at least means that the public servers are never really more than 3 months
out of date, and presumably not too much stuff will change in that 3 months
(and, up to the server admin, if some cool feature they really want now is
available in CVS, they could grab it and backport it to their stable copy)

 Note also that doesn't mean that no development happens in the third month - it
really just means nothing gets checked in.  The super cool XYZ could get written
in the first week of the month - you just need to wait until the next month
before checking it in.  We would probably need some way to handle the checkins
and deal with the merges - the first person to pounce in after the message
saying it is OK to check things in shouldn't necessarily always be the person
who never has to worry about merging possible conflicts.  Perhaps something of
the nature of people in the last week of that month saying what stuff they want
to check in, what files it affects, and how many lines in that file.  If one
person has 300 lines modified in that file, and another has 10, that person with
300 should probably have precedence, because merging in 10 will almost certainly
be easier than 300 (this is a rough approximation - if that 300 lines is just a
few new functions at the end of the file, those 10 lines may actually be tougher
to merge in than that).