Greg Stein <[EMAIL PROTECTED]> writes:
> On Thu, Aug 23, 2001 at 02:53:03PM -0400, Greg Ames wrote:
> >...
> > However, the bugs are getting more subtle and take longer to debug and
> > fix. With our current process, a great deal of new code can be
> > committed while the gnarly problem in last tarball is being debugged.
> > Why would we think that the new code is any less likely to contain
> > serious bugs than the previous set of changes? How do we get off this
> > treadmill?
>
> We got "off the treadmill" by stopping this silly business of holding up
> tarballs.
>
> Snap a tarball. Give it a once over. Release it as an alpha. Bam. Done.
>
> Come back a week later and upgrade it to a beta. Not so hard.
I don't think you can accurately equate the desire by some people to
put together a tarball which they expect will be of beta quality with
"holding up tarballs." Anybody that wants an alpha is free to do so.
As it stands, it seems that the only folks that are interested in a
tarball only want it if they think it is beta quality. Somebody who
isn't so picky is free to follow the process you outline above. As
long as those who want a beta tarball are helping the code base I
think they should be allowed to deviate from that process (e.g.,
re-tag files later when necessary fixes are applied, in effect
maintaining a virtual tarball until it is ready).
As I see it from the frontlines of debugging the current code, the
test/debug cycle, and its overlap with lots of activity in HEAD, is
what is delaying a beta tarball. I don't see how the process you
outlined is going to change that, unless there are some different
psychological motivations in play which will reduce the amount of
activity in HEAD and/or apply additional effort to the test/debug
cycle.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
