[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn 1.0 in 2006 or now?

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2003-01-02 21:27:11 CET

Branko Čibej <brane@xbc.nu> writes:
> Regardless of the rest of this discussion, I think it is time to set a
> definite date on 1.0. I believe we're far enough feature-wise, and quite
> close to the required stability.

With all due respect to you, Perry, and Solo Turn, I think you're
wrong. We are not near the required stability. We have the features,
but there are still just too many serious bugs -- we've got seg faults
coming in with some regularity, for example.

I think a lot of us may have become so accustomed to the bugs that
we've forgotten what it's like to experience them for the first time.

Jim Blandy tells a good story about a similar situation:

When he was in charge of turning GNU Emacs 18.59 into Emacs 19, he was
naturally always using the latest development Emacs to edit itself.
It had plenty of bugs, but since he had to get work done and couldn't
fix them all at once, he just learned to avoid certain things. Don't
type this key sequence, don't move the mouse this particular way,
don't switch buffers in the following circumstances, etc, etc. These
little coping mechanisms became reflexive to him; pretty soon, he
wasn't conscious of them at all. He became very different from a
regular user.

When he finally released a Beta, the testers encountered all these
problems immediately, and started reporting tons of obvious bugs. Jim
was embarrassed. He'd "known" about them, but the workarounds had
become second nature, so he thought he had a useable editor when he
didn't quite.

We already have tons of people willing to start using Subversion right
now, as it is, and more arriving every day. The only reason to call
it "1.0" is to attract the mainstream users who want high reliability
and no suprises -- and if we're honest with ourselves, we need to
admit that Subversion is simply not ready for them yet.

The kinds of users who depend mainly on the label -- "1.0", "stable",
whatever -- to decide whether or not to try Subversion, are exactly
the kinds who will be put off if they encounter a seg fault or an
obvious bug. Since the only purpose of the label is to tell those
kinds of users "Yes, we're past all that stuff now", Subversion will
look very bad if it's not true. The damage to faith is instantaneous
and severe, and won't be recovered from quickly. The user will go
away for a year or so, and overall we'll get a much slower adoption
than we could otherwise have had.

On a semi-related note:

The arrangement of issues in the Subversion issue tracker is far from
random. It results from Ben Collins-Sussman, Greg Stein, Mike Pilato,
and me all sitting around a whiteboard and considering *every single*
issue that was then categorized as pre-1.0. Our explicit goal was to
move as many of them as possible to post-1.0. That means the ones we
left in pre-1.0 are there because at least four developers thought
they were serious enough to need fixing -- four developers who badly
wanted to minimize the number of pre-1.0 issues.

So for what it's worth, my sense that Subversion's bug set is too
large and too serious for 1.0 is not derived from some vague,
hand-wavy feeling. It comes from having evaluated and discussed
*every single* bug, many of them more than once. If you haven't done
so, you really should try reading over all those bugs, and see if you
still feel we're near 1.0 afterwards.

Solo Turn, I notice that you didn't even mention issue #689 in your
proposed breakedown, neither for pre-1.0 nor post-1.0. Yet it's
perhaps the most serious issue in the tracker right now, one of the
few where I would unhesitatingly veto a 1.0 release if it remained
unresolved. Scanning the summary list and getting a general
impression of stability can be deceptive...

Believe me, I hunger for 1.0 as much as anyone. There will no doubt
be more issue triage sessions, and maybe we can move some more things
past 1.0. But we have to remember what the label is for: reassurance.
Calling Subversion "1.0" doesn't affect its actual stability one bit.
Subversion won't be any more "finished" the day after we release 1.0
than the day before. So if you know someone who is waiting till
Subversion reaches 1.0, and your own testimony isn't enough to
persuade them that it's ready now, then they're probably right -- they
need to wait until 1.0, and we need to make sure that 1.0 means what
they expect it to mean.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 2 22:10:52 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.