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

[Tim Rightnour]

On 03-Jan-02 Mark Wedel wrote:
>
     
       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.
     
     
While I don't specifically object to the idea.. I personally do not like the
idea of releases being time-bound.  It causes a few problems:

1) The quality of each release isn't as high, because we are just arbitrarily
saying "it's time", not "the features justify it being time"

2) A lot of time is spent doing release engineering type foo, like mark
mentioned.

3) The freeze period before each release is only useful given two circumstances:
 a) servers are running the release candidate.
 b) people are fixing bugs.

Now the issue with the second is more complex.  When you do one release every
now and then, when features demand it.. people tend to jump on board, and help
out in the debugging.  But when releases are commonplace, and occur on a set
schedule.. eventually people stop worrying about the release, because we can
just wait until the next one.  They may be too wrapped up in writing whatever
code it is they are writing to stop and go on a bug hunt.  This happens less on
a feature-demanded release, because generally everyone is in agreement that
it's time to release.

When you don't have a large number of developers..  these mandatory freezes end
up just being stale-time where nothing really gets done.

>
     
       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)
     
     
Unfortunately.. I think the public servers will end up running CVS regardless. 
Like mids said, bleeding edge is where people want to be.

I think instead.. we need to come to some understanding about what the CVS
really is.  To some degree, people have to understand that it's not allways
going to be perfectly stable.  But as long as it doesn't stay that way for an
inordinate amount of time, I think thats reasonable.

Case in point, my recent explosion:

I ran around on my server loading and unloading maps, playing the game, futzing
around.. and spent about 7 days mucking with things.  Now I missed a few
things, for instance I missed the unique maps.. thats purely my fault.

But there were a bunch of things that just completely threw me for a loop, like
how often mids's server crashes.. causing way more overlays than I had
anticipated to be made.

The point however is, that when it was brought to my attention, I fixed it,
right away, and backed out what I couldn't fix.  Personally, I don't think this
was unreasonable.  Yes, I broke it, yes, it caused some chaos, but mids should
have backed up his old binary, and I fixed the problems brought to my attention
almost immediately.

I do however. Like Mark's idea of having set things to test when mucking with a
certain peice of code.  Some of the interactions that occured on mids's server
were wholly unexpected by me, and a few could have been caught.

Worth noting though.. Is that the two hours I spent asking mids questions about
what was going on in his server (a heavily loaded server), was more productive
debugging time than I had spent the previous seven days.

I personally think people need to expect CVS to be unstable at times.  But they
also should expect that such instability, should be fixed within a reasonable
timeframe (1-2 days) or backed out.

---
Tim Rightnour <
     
     root at garbled.net
     
     >
NetBSD: Free multi-architecture OS 
     
     http://www.netbsd.org/
     
     
NetBSD supported hardware database: 
     
     http://mail-index.netbsd.org/cgi-bin/hw.cgi