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

Thu Jan 3 23:45:41 CST 2002

Bob Tanner wrote:

>

      Most irc clients have logging capabilities. When one of these discussions takes

     >

      place couldn't someone log it and then send it to Leaf to have it posted to the

     >

      website or have the logger send it to the crossfire-devel list?

 That certainly works, but you need to remember to do it.  For purposes of
discussion on the mailing list, it still helps if it gets written by hand to
really concentrate on what is relevant - often times, the discussion may be
pretty long but the proposed change can be concentrated into just a few
paragraphs.

 I don't think the difficulty of writing to the mailing list is really the
problem - relative to the size and time needing to code many of the things,
sending a few paragraph description of what you plan to do is really a small
portion of the time.

 the problem is that crossfire has probably never really had a formalized
procedure for committing to CVS.  If your change is widely accepted as a good
idea and does not hvae any serious bugs, you can get away with committing it
with no real discussion, because no one will really care.  It is when the idea
may not be quite so widely accepted or have serious bugs that problems arise. 
Unfortunately, there is no way to really no what category it will fall into
unless mail is sent out.

>

      IMHO this is the biggest issue with the crossfire project (and all the other

     >

      open source project I contribute to). No test suite, so it's almost impossible

     >

      to know if your code integrates correct until someone installs it on their

     >

      server and people play test it.

 Yes - the obvious reason is that writing a test suite is not that intesting of
a thing to do (I know personally that I would rather implement new features than
spend time working on a testsuite).  Also, the fact that you already have free
testers probably contributes to this (eg, why should I spend a lot of time
trying to test every case when it can go into CVS and those boundary cases and
so on will get tested by others).

 I think it is relative safe to say that no one checks in code that they know
has errors.  I know I have checked in code which I thought was OK but errors
were discovered.

 Why writing testsuites may be require a lot of time, I think writing testplans
would be useful and not take as much time.  If for example, we had a testplan
for exit and map loading/saving, there is a very good chance that Tim would have
caught the problems with the overlay code.  Testplans only need to consist of
things like 'try these things out', so it is just a matter of writing down
text.  IT would probably be useful for people, when they develope their testing
strategies for something they are working on, to share it.  The test plan does
not need to be really detailed, for example, an exit and map load/save test plan
may be:

1) Enter map not loaded before.  Does it load correctly.  Leave an item there
for future reference.
2) Exit map and re-enter quickly.  Is it loaded correctly?  Is that item you
left there?
3) Exit map, and wait for it to swap out.  Then re-enter.  Is that item there.
4) Repeat steps 1-3 with a per player unique map.
5) Repeat steps 1-3 with a map that has the outdoor flag set
6) repeat steps 1-3 with a map ....
7) Kill server, and re-run tests.

 Not very detailed, but gives an idea of what to test for.

>

      Doesn't this "break" the open source mantra of release early, release often?

     >

     >

      Part of the problem is stability of a release. We don't roll a release until

     >

      it's stable. But we don't know if it's stable until we release it.

     >

      Chicken-n-the-egg thing.

 Once every 3 months may be more often (certainly is has been more than 3 months
since the last release).

 One problem with doing releases is that they take some amount of time to do
properly (my basic procedure is to archive it up, un-archive it someplace else,
then make sure it builds and runs correctly).  Doing that tends to take a non
trivial amount of time.

 I think the release schedule would also vary a lot based on how much stuff
changes.  There isn't much point to release every 2 weeks if in some cases, the
only thing that changed in that two week period are some very minor fixes.

 Alternatively, I could freeze CVS whenever I think enough stuff has changed to
warrant a release.  The problem is that if the freeze time is known in advanced,
people try to stuff in their latest cool enhancement before the freeze time, and
those last minute changes are more likely to have bugs which can only really be
found during the freeze time (which then means the freeze should probably be
longer).  For example, if I sent out a mail saying I'm going to make a new
release, and freeze any new commits in one week, there would probably be some
number of commits done perhaps more hastily because they want to get in before
the deadline.

 OTOH, if I just announce that the source is now frozen with no deadline, I'm
sure some people might get upset that they can't get their latest change for the
next official release.  That is one reason I thought having real schedule might
work - you really know when you have to get your changes in by.  Now there could
still be cases that it is 5 days until the deadline and you really want to get
your code in.  But at least if there is a known schedule for releases, you know
worst case your code will be in the one three months from now.

 Note that releasing once a quarter was a fairly arbitrary time frame.  We could
do once a month, and have a 1 week freeze instead.  IF in that particular month,
not much got done, we skip the release cycle for the month.

Joris Bontje wrote:

>

     >

      I think that we don't have enough coders too keep up 2 branches, maybe

     >

      I don't understand the work involved completely but merging those two

     >

      branches together after a new release looks like black magic to me.

 A lot depends on how this is done.  The biggest problem is when do you decide
to rebase and take what is currently in CVS and make that your 'stable' branch
(or at least work towards that)?  In that case, you may now have 3 branches -
your 'old' stable release, your bleeding edge potentially unstable, and your
'new' stable release, which your still working on making stable.

 What it really takes to have a stable branch is for someone to watch the
commits - when they see something that is a bug fix only, the merge that into
the stable branch.  Likewise, any stability changes they make to the stable
branch, they also make to the main branch.

 The problem comes that the more the main branch deviates from the stable
branch, the more effort this becomes (porting the changes between the branches
may no longer be just a matter of copying the code).  Likewise, if the stable
branch is too old, people probably won't be as interested in using it.

>

      Ofcourse I could run two server. But there will be some problems:

     >

      technical:

     >

      - metaserver doesnt support 2 servers with different ports on 1 ip/hostname

     >

      - my server can't handle the load, I wil have to use my workstation as a testing

     >

      server (I have done that before with iso maps and scriptfire/plugins)

     >

      non-technical:

     >

      - we don't have enough players to fill all those servers!

 Right - if the two servers are operating on different data files (maps,
players, etc), then thats basically the same as just having to totally different
servers unrelated to each other.  If they operate on the same data files (so
that if server 1 is too unstable you go to server 2), crossfire currently
doesn't support that.  Also, that doesn't help if there is some bug in server 1
which just trashes the player file.