[thesite] Re: test.evolt.org

Dean Mah dsmah at home.com
Tue Apr 17 18:06:32 CDT 2001

Yeah, I remember that.  The problem with SourceForge is that (I don't
think at least) you can't push the changes that you have commited into
production immediately.

For small changes (bug fixes) and since we don't really have a QA
process, you need this ability.  Without it, you have to make your
changes, wait for a vote on the changes (QA), commit, and then wait
for someone with authority to grab the code from SF push it into
production.  This process is too heavy for some of the developers and
so they will tend to ignore it and go outside the process.  Or say
'screw this' and leave the company which is what I did (but our
process was a lot heavier, e.g., we were warned that if we touched the
code outside of an assigned bug or feature enhancement that we could
be fired).


Daniel J. Cody writes:

> I'd love to go to a CVS stype enviornment.. 
> However, I remember when I tried to push all thesite code into a
> sourceforge CVS account, no one would touch it with a 5 foot stick.
> *shrug*
> Dean Mah wrote:
> > 
> > In a previous environment that I worked in, we used CVS to handle the
> > concurrent development updates.  We had an automated process that did
> > pushes from CVS fixes branch into production every morning.  For
> > critical fixes, there was also a manual scripted way to push changes
> > immediately into production.  Any large scale development would be in
> > a CVS dev branch that would be synchronized with the fixes branch
> > periodically.
> > 
> > This was the ideal situation for us.  People that needed to push
> > changes into production immediately could while people that
> > wanted/needed/were required to have their changes QA'ed could have
> > that done as well.  And then depending on the branching structure, we
> > could have an area for long-term development.
> > 
> > Dean

More information about the thesite mailing list