On Wed, 2004-01-07 at 07:07, Greg Stein wrote:
> 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.
[...]
> > 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.
I don't think you can have this both ways. The milestones in the issue
tracker were used to make the decision that it was time to stabilize for
the release. The CollabNet people exercised control over the milestones
in the issue tracker. Ergo, the CollabNet people have been setting 1.0
release policy, to a greater extent than the rest of the community.
When Karl makes changes like this in the issue tracker, he usually says
he's open to discussion about it. But even with that caveat, when he
overrides someone else's classification of an issue, he's determining
the status quo ante for any conversation about the issue, and that can
be a powerful factor. (One could reverse his changes by fiat, but only
at the risk of devolving into schoolyard behavior.) In the case of the
issue #999 milestone, there wasn't even a suggestion that the decision
was open to change.
Is this process efficient? Yes; it's much faster than it would be to
review and classify many issues on the mailing list. But it does mean
there's been an inner circle as far as release policy, which means I get
to say things like "as a group, the inner circle hasn't been paying as
much attention as I'd like to the API as it relates to the 1.0 release,
and I'd like that to change." Which is essentially what I said.
> 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.
Indirectly, it does affect the users of the software, in proportion to
how many of them use svn through outside applications. If we consider
the API to be a secondary feature of the release, we may as well not
have it. (perl provides an excellent example of a package which has a C
API and may as well not, because it considers the C API a highly
secondary feature of the package and consequently provides miserable
compatibility guarantees.)
So, strong disagreement on this point.
> 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.
The people I talk to are mostly concerned with how much svn is a moving
target. They don't want to have to dump and load their repositories to
update their server, or worry about keeping clients and servers in any
kind of sync. In the future, they also won't want to have to worry
about whether upgrading svn will break an application using our API, or
whether it will break scripts they've written. So it's not just
important that svn 1.0 works well. The version number is not a stupid
label.
> 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.
We can't get it perfect, but we can fix the problems we know about.
Anything we don't fix now will result in more pain later--not just for
us, but for the consumers of our API, which will grow more complicated
and difficult to navigate as we add rather than change functions.
Elsewhere, Greg Stein wrote:
> One of my underlying reasons for avoiding API changes right now is
> that you can view the set of available software as a sort of
> "ecosphere" of tools around SVN.
I want to address this because, on the face of it, it appears to put us
on the opposite side of the API-importance table from where we were
earlier in this message.
We've never claimed that 0.x releases have a fixed API, and in fact
we've made a large number of API changes between 0.x releases in the
past. We've known that early adopter projects like TortoiseSVN and
RapidSVN suffer as a result of API changes, but they're early adopters,
so that's acceptable. We should not use them as an excuse to avoid API
changes now, while we're still in the 0.x cycle, at the expense of
making the SVN 1.1 API more baroque than it has to be.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 7 20:47:17 2004