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

Re: stabilization & number of changes

From: Greg Stein <gstein_at_lyra.org>
Date: 2004-01-07 13:07:22 CET

On Mon, Jan 05, 2004 at 06:16:20PM -0500, Greg Hudson wrote:
> I'm not saying that CollabNet developers made more API mistakes than
> anyone else during the general course of svn development. I'm talking
> specifically about an attitude towards the relationship between API and
> the 1.0 release. Here's my perspective:
> * There was a push, largely from inside CollabNet, to stabilize and
> release 1.0 starting with 0.35. This decision seemed to be based
> largely on the state of the issue tracker and the lack of critical
> bug reports from users.
> * There was a corresponding push, largely from outside CollabNet, to
> make sure that 1.0 is not just good from a usability perspective but
> also a good platform to build on (mostly in terms of the API).
> * There has been pushback against this second push, largely from
> inside CollabNet. (To be fair, mostly just from kfogel and gstein,
> and Karl has been constructive and non-obstructionist as he pushes
> back.)

I wish you wouldn't attempt to portray such divisions. Some people happen
to be paid to work full-time on SVN, but I don't think that inherently
creates the kind of division you're talking about. All of us approach the
project with individual views and thoughts. Does each of us take the time
to fully explain our position? No. We simply work from that position and
trust that others will respect it. Mine is extremely conservative when it
comes to stabilizing; you'll note that Ben, Mike, and Karl aren't at all
like that, despite the fact that we'll all part of the "CollabNet crowd"
you're defining.

> Moreover, this has been a pattern going back a long time. I originally
> classed issue #999 as beta, because of its far-reaching API
> implications, but gstein unilaterally overruled that classification.

Ahem. That is untrue, so I wish you wouldn't characterize me that way. The
fact of the matter is that I was in Chicago the week of December 2nd,
2002. As usual, we went through all the open issues and made calls on what
would stop SVN from being able to be called 1.0 or not. Yes, I happened to
be the person who made the change in IZ, but it was far from unilateral.
The view of karl/ben/mike/me was that an API issue was not going to be
seen by the end user, so it was not necessary to hold 1.0 for it. That
never meant it couldn't be fixed before 1.0, but that we just didn't feel
like 1.0 needed to be held for it.

While I believe having a great API is nice, I don't see it as affecting
the users of the software. And it is the users who are our primary
audience. I happen to believe that those users would rather have 1.0 in
hand next month, than a clean-API-1.0 in April. (of course, it probably
wouldn't take that long, but if we *just* sat around cleaning the API...
then yah. it very well could)

Just this last weekend, some developers I spoke with said, "we aren't
moving because it isn't 1.0". I hear that *all* the time. But the fact of
the matter is that SVN is more than ready for users, but they don't
believe me when I tell them that. And it is all because of that stupid
label called a version number.

I happen to have a lot of faith that we can update the APIs moving
forward, and to do so in a compatible fashion. I also believe that we'll
never find them all now, so we may as well recognize that fact and move on
rather than making an attempt, in vain, to get it correct today. As long
as we get the big boys that are so egregious that we'll have a seriously
difficult time updating them later. (of course, the problem there is that
it is usually "too big" of a fix to correct it at this point)


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 Wed Jan 7 13:12:46 2004

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.