On Fri, Jan 03, 2003 at 09:28:41AM -0800, solo turn wrote:
> 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)
And that bug is why we aren't beta. And numerous others. What's your point?
> - there is "beta" (after the fix of the issues mentioned),
> then there is "1.0".
And we define beta as "no known bugs", and sometimes refine that as "any
bugs have very simple workarounds or the bugs don't really affect user
functionality."
> and karl is trying to avoid jim's beta experience ...
> but thats why "beta" is there, to FIND THESE BUGS.
Nah. We said that is what alpha is for.
Sorry, but as Ben said: we're a version control system. As a result, we've
defined the alpha/beta/final release criteria with a *lot* of conservatism.
We want to tell people, "this is rock solid. you can entrust your corporate
assets to it." When companies have *millions* of dollars at stake, it tends
to produce a very conservative behavior.
"But Open Source developers don't need that." Sure they do. They don't have
*money* at stake, but they certainly have personal time involved. And their
experiences with Subversion are *precisely* the mechanism whereby SVN earns
its "rock solid" description. Without the OSS community, SVN could never
reach such a label.
I believe most of the active developers tend to agree with this. We want a
solid reputation, and we're willing to give SVN the time it needs to reach
that. Taking over the world doesn't have to happen *tomorrow*. If it takes
another few months? Fine. The simple answer is that if SVN is rock solid,
then we *will* become the dominant OSS version control system. My confidence
level in that is huge, and it depends on taking a conservative approach.
I'll trade a few months for that guarantee of being known as the OSS
community's version control system.
>...
> not going beta is bad for everybody. new features can't be
> added (as we soon have 1.0 ... in 2004), mainstream users
We aren't adding (big) features now. Little ones are sneaking in, but we're
resisting, and I'm certainly telling the guys in Chicago to avoid adding
them (yes, this is one area where I get to exercise a bit of mgmt muscle).
Ben added the auto-versioning stuff, but that was on "his time" rather than
on CollabNet time. (but I'm not actually going to complain :-)
> 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?).
August? Where'd that come from? We haven't set a release date. I've
generally been thinking something like March or April.
> 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.
Well, goody for you. We've got some experience, too.
>...
> 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????
It was marked as bite-sized with the hope that others would take care of it
(and put in 0.19 to give them plenty of time). In fact, Matt Kraai did
exactly that with commit r4117. The reason it got left is that compiler
warnings can be indicative of real bugs. Karl just fixed a potential
NULL-deref yesterday, clued in by a compiler warning.
It was a choice we made, and I'm still alright with it. Note also that we'd
have another review of it when 0.19 came around. It could very well be that
we would have deferred it at that point, if it hadn't been fixed.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 3 21:18:05 2003