So I guess if I find a typo in the build script, but otherwise the software
works perfectly, then the burn in period will be reset? I'm sorry, but I
still don't get it. To me the idea of a release candidate is to make sure
that the application works, not that someone can build it correctly. This
is not to mention that not only do you have to worry about real bugs in your
release candidate, but you have to worry about people who don't have a clue
of how to build Subversion building it the wrong way and then reporting bugs
based on that?
Also, does it really make sense to have the Subversion developers (these are
the only people that know how to build Subversion) themselves testing their
own application and effectively being the only ones to sign off on this
"release candidate"?? Isn't this like one of the golden rules of software
development?
If the release is being delayed because of a dependency on Apache that is
one thing, but if the expectation is that a bunch of end users are going to
take the time to setup a build environment, figure out how to build the
software and then test this "release candidate"... which happens to be a
major change over previous versions and you would think would require lots
of testing before it's signed off on... then IMHO that is crazy.
Eric J. Smith
> -----Original Message-----
> From: Max Bowsher [mailto:maxb@ukf.net]
> Sent: Tuesday, April 12, 2005 2:23 PM
> To: Eric J. Smith; users@subversion.tigris.org
> Subject: Re: Subversion 1.2 RC1 Binaries
>
> Eric J. Smith wrote:
> > Personally, I don't see how you can have a RC1 release with no binaries
> > and
> > kick off a burn in period based on that.
>
> The build process is one of the things that we want burnt in!
>
> Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 12 21:46:44 2005