hmm ... karl .. the problem is that you are definitly
not wrong ... BUT:
- you seem to be in the same situation as jim blandy,
brilliant and blind for mainstream users needs
and expectations
(add -R choking for existing files/dirs for example,
... every newcomer falls over that)
- there is "beta" (after the fix of the issues mentioned),
then there is "1.0".
and karl is trying to avoid jim's beta experience ...
but thats why "beta" is there, to FIND THESE BUGS.
and it does NOT matter if there is a few bugs you
know about.
not going beta is bad for everybody. new features can't be
added (as we soon have 1.0 ... in 2004), mainstream users
needing a time schedule getting fed up (what are these
svn guys doing, they say august, but maybe they forgot
the year? is that the new opensource?).
i'm doing basically nothing but "release management" for
the last 10 years ... and i know about arguments for and
against a release ... and i also know when it is a good
time to do a release. from a users point of view, not
from a developers point of view.
some of the decision points for "release now" are:
- new features, new development branches (like
caching, ...)
- new architecture ("rewrite client")
- new base software (new berkely db version)
- seg faults coming IN (they were not there
before)
and i want to mention one example of a not at all
important (even if 4 developpers carefully thought
about that) task:
1031 DEFECT P3 All issues@subversion NEW
gcc3.3 compile warnings
why the heck is a "upcoming gcc 3.3 compile warning"
prevent subversion from going beta????
and the others mentioned are not quite as obvious,
but the same category.
and i like brankos idea of the 1st of april,
nobody will blame you :))))
solo.
ps1:
we are using subversion with new users all the time,
one by one and are pretty sure what they need, and what
they want. and our users are microsoft point and click
users ... hardly any cvs/unix involved.
ps2:
for issue 689: i did not mention it, as it is where
it belongs: the next thing to be done.
--- Karl Fogel <kfogel@newton.ch.collab.net> wrote:
> 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.
>
> -Karl
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 3 18:29:27 2003