On Tue, Jun 11, 2002 at 06:46:40PM -0700, Greg Stein wrote:
> So. What do I mean by Alpha?
> "All major features, necessary to accomplishing the tasks you would expect
> Subversion to accomplish, have been completed enough to be functional for
> the majority of use cases."
I would add:
"All features which would need a change in user interface have
been completed at least on the user interface."
This is because people would get very upset if you change the user
interface after 1.0 release. You need not to implement the feature
right now (you can implement it at release 3.0 for example). But you
should adopt the user interface so that it would stay the same if the
feature will be implemented in release 3.0 or so.
In this context I would like to discuss such a beast: a change which I
would like to see in some $BIGNUMBER release and which is likely to
change the behavior of the user interface in a way which would make
people upset. (But this is not the right time/place to discuss this)
> The Alpha release is intended for actual use scenarios.
Yes. Therefore all known big issues (which destroy the repo or the wc)
should be turned at least into little issues (destroy in a way so you
can recover somehow)
Yesterday I played with "svn update -r XYZ" from the original svn
repository to find out which commit broke the bug which at last was
fixed in r2160. Originally I was on r2157 (which was the newest at
that time). From that I "svn up -r 2024" (I assumed this release did
not contain the bug). This crashed and left my WC in a state which I
could not recover from. I checked out the newest rev again and
"svn up -r 2093" (because of the switch in repos format). Crash
again. Unpack latest tarball and "svn up -r 2130". Crash again.
Check out newest and "svn up -r 2135". Crash again. At last I could
identify r2131 to introduce the bug.
I think "svn up -r XYZ" _is_ an "actual use scenario". Please dont
misunderstand me: crashing is OK in pre-alpha. But if you announce
Alpha, _more_ people will come to take a look. If they experience such
crashes, they will run away and shout out loudly. And those people will
advocate: "It's crashing all the time. You dont really want to use it"
Therefore it is better to delay alpha as long as crashing issues are
BTW: It loks to me that most of the crashes I expirienced yesterday
were caused because of files were added/removed/moved/copied. I
want to investigate this in the near feature. But I think
you will be out with Alpha before I finish with this ;-))
> One more point of contrast is "what would a Beta be?" We're currently
> defining Beta as:
> "We don't know of any bugs that prevent the use of Subversion. As far as
> we're concerned it is at a release quality level, but we want to be
> conservative and get some shakedown first. [especially as a high
> confidence level is required for a version control system]"
> 2) Agreement on shifting the current Alpha bugs to beta, the current
> pre-alpha bugs to Alpha, and releasing Alpha when they are fixed.
I dont think it is good strategy to shift crashing issues (and there
are a lot of them) into beta just to get out alpha earlier. The more
stability you get in alpha the more people will give svn a try and
people will have more confidence into svn. This has to do with
psychology and is IMHO _very_ important for a project like svn because
svn can only be successful when people entrust it their sources!
For a project like svn "alpha" should be (internally) considered as
Once you have a discredit of "crashing often" it is very hard to
convince people of the opposite. So I vote to delay Alpha as long as
there are known "crashing" issues. Please dont hurry to get alpha
> Note that there isn't a real cutoff for end-of-voting, as we'll be reviewing
> periodically. In particular, I'm in Chicago again next week, and we'll be
> taking a hard look at what/when Alpha might be (and yes, we'll post here).
> An initial guess is in about two, maybe three, weeks.
Two/three weeks to vote or to get Alpha out? IMHO this is too short
> So again... Alpha is coming. We all are responsible for Subversion, and we
> all have our name attached to it. Pride of ownership also means taking pride
> in the quality. Speak your mind... please.
PS: OK, now it's your turn to flame on me ;-)
-- Josef Wolf -- email@example.com --
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jun 13 00:11:48 2002