You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/01/05 19:35:35 UTC
stabilization & number of changes
Greg Hudson <gh...@MIT.EDU> writes:
> > Holy crap... there are a lot of suggestions for the 1.0 branch. How can
> > this be called "stabilization" ?!!?!
>
> Because almost all the changes are small and have a good reason to be in
> 1.0. And compared to our normal development rate, it's really not that
> much.
A point about stabilization (I just said this in another post, but as
part of another topic, so will say it again):
Yes, there are a lot of candidate changes in the STATUS file. But
most of them are low-risk, and more importantly, can be merged
together & early into 1.0-stabilization. Thus, the total soak time
for that branch isn't increased in proportion to the number of changes
merged. The changes will soak in parallel, which is fine.
These changes would be objectionable if they were pushing back the
release date, but they're not. (We don't need to know the actual date
to make this statement, of course; which is good, because it's not
getting set until Thursday.)
> I'd also like to note that "1.0 stabilization" came up on at least one
> developer (me) by surprise, and was largely driven by a developer (Karl)
> who seems to have a very optimistic perspective on how easy it will be
> to fix or work around API problems in the post-1.0 world. Issue #999
> would have been taken care of beforehand if I'd had a little more time,
> for instance. I didn't ask to put off branching, but I'd like to see a
> bit less reticence to fix API problems among the CollabNet crowd, since
> that same crowd does not appear to have put much consideration into the
> API before driving the stabilization process.
<mildly arched eyebrow>
The CollabNet developers put as much thought into APIs as anyone else.
There's never been a guideline in this project that says "We don't
have to think hard about the APIs we create until we get near a major
release, at which point we can just clean them up."
If we (I mean everyone, not some subgroup of developers) made poor API
choices, then we made poor API choices. It's neither more nor less
serious because it happened long before stabilization began.
Don't get me wrong: it's fine to clean this stuff up. But our policy
should always be to try and get an API right the first time, and that
responsibility is not more incumbent on those who suggest starting a
stabilization process than on anyone else.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by kf...@collab.net.
"Erik Huelsmann" <e....@gmx.net> writes:
> Sure, you are in one office and full-time employed to work on it. Although
> you may not want there to be a division this automatically creates
> one: for me the only logical way of discussion with Karl is the dev@
> list; for you it's to walk up to him. [...]
A couple of points:
Greg Stein works in the California office; Mike, Ben, Fitz, and I work
in the Chicago office. So Greg doesn't "walk up" to us to discuss
Subversion stuff :-).
But more significantly, notice how Ben and Mike have put +1 or +0 for
many items in the STATUS file where gstein has said -0. I think this
ought to dispel any myths about CollabNet's supposed unity :-).
(That's a response more to Greg Hudson's mail than yours, Erik.)
What's really going on here is:
Ben and Mike are more liberal about approving changes, Greg Stein is
*much* more conservative, and Karl is somewhere in the middle. This
is because they are individual developers, with different
personalities and different prior release experiences -- like the rest
of this list. We may share a common employer, but you don't see us
toeing a common line in the STATUS file.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Erik Huelsmann <e....@gmx.net>.
> On Wed, 2004-01-07 at 15:34, Erik Huelsmann wrote:
> > Greg, (not sending to your personal address which has this hideous
> > mail-received notification)
>
> Come on, the 'hideous' thing only pops up once a month ;).
>
> > > 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
> >
> > [ large snip ]
> > > I wish you wouldn't attempt to portray such divisions.
> >
> > [ extremely large snip about marking issues Post-1.0 unilateral or not ]
> > > 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.
> >
> > I can't help reading that you *do* make the division yourself too.
> >
> > Sure, you are in one office and full-time employed to work on it.
> Although
> > you may not want there to be a division this automatically creates one:
> for me
> > the only logical way of discussion with Karl is the dev@ list; for you
> it's
> > to walk up to him.
>
> heh heh. Nope. Different offices with a plane flight in between ;).
/me hides in a little corner ...
Ok, but it's still the same company. My company operates all over the world;
I call my co-workers on the other side of the globe far easier then I would
pick up the phone to call any one involved with Subversion.
> > It is not necessarily bad and does not have to mean "us"
> > against "them", but it does mean that opinions of those at CollabNet
> have been
> > and are going to be taken differently than from others.
>
> There will be different priorities, but that's about it. And to credit
> CollabNet, the priorities of the community are as much respected as that
> of the company itself at this point.
Yes. I don't want to sound disrespectfull in any way: I *very* much like
what is done and how the community also can give it's input to the project.
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by "Mr. Spook" <jo...@josander.net>.
On Wednesday 07 January 2004 16.21, Sander Striker wrote:
> > Sure, you are in one office and full-time employed to work on it.
> > Although you may not want there to be a division this automatically
> > creates one: for me the only logical way of discussion with Karl is
> > the dev@ list; for you it's to walk up to him.
>
> heh heh. Nope. Different offices with a plane flight in between ;).
>
Uhh.. No engage?
Spook
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Sander Striker <st...@apache.org>.
On Wed, 2004-01-07 at 15:34, Erik Huelsmann wrote:
> Greg, (not sending to your personal address which has this hideous
> mail-received notification)
Come on, the 'hideous' thing only pops up once a month ;).
> > 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
>
> [ large snip ]
> > I wish you wouldn't attempt to portray such divisions.
>
> [ extremely large snip about marking issues Post-1.0 unilateral or not ]
> > 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.
>
> I can't help reading that you *do* make the division yourself too.
>
> Sure, you are in one office and full-time employed to work on it. Although
> you may not want there to be a division this automatically creates one: for me
> the only logical way of discussion with Karl is the dev@ list; for you it's
> to walk up to him.
heh heh. Nope. Different offices with a plane flight in between ;).
> It is not necessarily bad and does not have to mean "us"
> against "them", but it does mean that opinions of those at CollabNet have been
> and are going to be taken differently than from others.
There will be different priorities, but that's about it. And to credit
CollabNet, the priorities of the community are as much respected as that
of the company itself at this point.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 07, 2004 at 03:34:35PM +0100, Erik Huelsmann wrote:
>...
> I can't help reading that you *do* make the division yourself too.
>
> Sure, you are in one office and full-time employed to work on it. Although
> you may not want there to be a division this automatically creates one: for me
> the only logical way of discussion with Karl is the dev@ list; for you it's
> to walk up to him. It is not necessarily bad and does not have to mean "us"
> against "them", but it does mean that opinions of those at CollabNet have been
> and are going to be taken differently than from others.
Historically, the four of us have been the ones to set milestones in the
issue tracker, but that is about the only functional difference within the
community. The underlying reason is that we're setting those by using
standard corporate dev methodology: what are we going to work on? and
when? The other people in the community work on things as they desire, and
if that happens to be in a post-1.0 issue, then so be it. You'll find a
lot of issues with a note that says, "not required for 1.0, but it would
be great if somebody wants to do this sooner."
There have been times when other people in the community have monkeyed
with the milestone, effectively saying, "I'll finish this by <that>
release." Of course, doing that on a volunteer / free-time / interest
means that sometimes it is really a few releases later :-)
As Karl responded, we happen to work in separate offices, but that misses
the point that Ben, Karl, and Mike *are* in the same office and can just
turn around and talk to each other. There are other "back channels", if
you will, such as the phone and an internal IRC server, that we use.
However, we are very sensitive to using those. Probably three years ago,
we made some design choices and just started implementing them. It was the
right design to do, but we hadn't discussed it at all with the community,
and we rightfully caught a bit of flak. Since then, we post that stuff
first. You'll find many posts from Ben that start with something like,
"gstein and I were talking..." But when it comes to the issue tracker, we
just make those changes since they are "in public view" anyways. It is
very easy for the community to tweak or discuss the changes that are made.
So... it's quite fair to say that I'm rather sensitive on the topic.
CollabNet does not want to hold or enforce any particular position; it is
best for us and the community to avoid stuff like that. There *are* people
who are "leaders" in the community, as with any other open source
community, but that is earned through respect rather than corporate
affiliation. People like Greg Hudson and Branko have been around for years
and are well-respected, despite none of us really knowing the name of
Branko's company. (we know that Greg works at MIT, tho)
Personally, I've been involved with the project for nearly four years. The
only other contributor that has been involved longer is Karl. Jim Blandy
started the SVN design with Karl, but he isn't really involved nowadays.
Even after I joined CollabNet, I continued to use my @lyra.org address
since that is "me" within the SVN community. At some point, I might
actually post with @collab.net when I need to ask people to send in some
kind of a contributor agreement, and that *will* officially be "the Greg
Stein who works at CollabNet" at that point.
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
Re: stabilization & number of changes
Posted by Erik Huelsmann <e....@gmx.net>.
Greg, (not sending to your personal address which has this hideous
mail-received notification)
> 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
[ large snip ]
> I wish you wouldn't attempt to portray such divisions.
[ extremely large snip about marking issues Post-1.0 unilateral or not ]
> 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.
I can't help reading that you *do* make the division yourself too.
Sure, you are in one office and full-time employed to work on it. Although
you may not want there to be a division this automatically creates one: for me
the only logical way of discussion with Karl is the dev@ list; for you it's
to walk up to him. It is not necessarily bad and does not have to mean "us"
against "them", but it does mean that opinions of those at CollabNet have been
and are going to be taken differently than from others.
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Mike Mason <mg...@thoughtworks.net>.
Greg Stein wrote:
>On Wed, Jan 07, 2004 at 11:00:03AM -0500, mark benedetto king wrote:
>
>
>>...
>>You're right; there are hoardes of people waiting for 1.0 to adopt svn.
>>I'm one of them. The cost of an API change is probably proportional
>>to the number of users; let's try to injure only the early adopters,
>>rather than the masses.
>>
>>
>
>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. If we change the API now, then it ripples throughout
>that entire ecosphere and tightly couples versions of each against each
>other. If we tweak the API, then suddently RapidSVN no longer works. The
>user will have to upgrade that. Oh, and their buddy's Windows box will
>need a new TortoiseSVN to deal with the new SVN. etc.
>
>
But that's true of anything that's compiled against a library, isn't it?
If I upgrade Subversion on my server, I probably have to upgrade my
clients. I'd then at least have to upgrade the library that Tortoise is
(dynamically?) linking against. I do agree that changing the API will
cause ripple effects, but I think a lot of people developing tools are
waiting for the magic 1.0 stabilisation line before themselves doing a
final push to work with Subversion.
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 07, 2004 at 11:00:03AM -0500, mark benedetto king wrote:
>...
> You're right; there are hoardes of people waiting for 1.0 to adopt svn.
> I'm one of them. The cost of an API change is probably proportional
> to the number of users; let's try to injure only the early adopters,
> rather than the masses.
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. If we change the API now, then it ripples throughout
that entire ecosphere and tightly couples versions of each against each
other. If we tweak the API, then suddently RapidSVN no longer works. The
user will have to upgrade that. Oh, and their buddy's Windows box will
need a new TortoiseSVN to deal with the new SVN. etc.
It would be great if we could just tweak the API, but it affects a lot
more than just SVN itself.
Post-1.0, we'd be making those tweaks in a compatible fashion, so it
wouldn't really matter. We wouldn't see this kind of coupling (what'll
happen is that a new client might force a point-upgrade of the core SVN
rather than the other way around). But right now, we're looking at making
the tweaks incompatibly (note: across the board rather than just the date
parser).
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
Re: stabilization & number of changes
Posted by mark benedetto king <mb...@lowlatency.com>.
On Wed, Jan 07, 2004 at 04:07:22AM -0800, Greg Stein wrote:
>
> 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 am not using svn at work because it isn't 1.0.
This isn't because I don't trust it, don't think it's ready, or don't think
it doesn't kick the crap out of the VCS system we're using now.
It's not even because of the date parser. :-)
It's for one simple reason: compatibility. When I ask my team to download
svn and subclipse and rapidsvn and tortoisesvn and svnup and so on, I only
want them to have to do it once. There have been so many times that I've
wanted to switch, but the moving target of the API has prevented me.
Each time we break the bindings I congratulate myself for my restraint.
If one was interested in svn for its features, probably 0.15 or so would
have been good enough. If one was interested in svn for its stability,
probably 0.25 or so would have been good enough. If one was interested
in svn for its speed (I wasn't; my repos are comparatively small), probably
0.33 or so would have been good enough.
What else is left, IMO? Compatibility. That's all I'm waiting for.
You're right; there are hoardes of people waiting for 1.0 to adopt svn.
I'm one of them. The cost of an API change is probably proportional
to the number of users; let's try to injure only the early adopters,
rather than the masses.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Folker Schamel <sc...@spinor.com>.
My 3 cents (from my perspective as software developer):
If fixing a problem will require an API or
functionality change, delay 1.0 and fix it NOW!
Otherwise you have to pay a high price:
After 1.0, 100 times more users and developers
will be affected by API and functionality changes,
or if the problem is not fixed because of compatibility.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Erik Huelsmann <e....@gmx.net>.
[ snip agreement on good and stable API to which I agree too ]
> > 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.
>
> I'd say Greg Stein's comment here is an argument for making the changes
> now. If we want to view things as a group then we might as well get the
> pain overwith. While we're doing our soak time, why not spend some time
> going to the various projects using subversion and trying to cordinate
> updated versions of their program to match our APIs?
This is IMHO a much better solution (ie. helping others out) to the changing
APIs problem then Greg Stein's especially since we never promised the APIs
would be stable. If we were afraid of breaking compatibility with current
clients we should have started using sliding API techniques long ago as these
clients did not pick up on Subversion developement yesterday. The authors of
these clients know that Subversion is not 1.0 yet, however they accepted that
fact and wrote their clients anyway (for which I'm glad).
If Greg Stein is afraid that after Subversion 1.0 the other clients won't be
able to release their newest clients soon enough, the above fixes that
problem way better. Why make our own lives (and those of other API users) after
1.0 more difficult than necessary?
> Looking at the votes we're going to have API changes betwene 0.35.0 and
> 1.0. So let's get the API stuff out of the way now.
>
> I'd be more than happy to spend some time working on helping get some of
> the other projects API issues dealt with. RapidSVN for example doesn't
> seem to keep up with subversion at all. ISTR it went from a 0.29
> compatable version to a 0.34 compatable version and within days 0.35 was
> released and broke it again.
Hear! Hear!
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Ben Reser <be...@reser.org>.
On Wed, Jan 07, 2004 at 02:46:26PM -0500, Greg Hudson wrote:
> On Wed, 2004-01-07 at 07:07, Greg Stein wrote:
> > 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.
I totally agreen with Greg Hudson on this point. The API will be my
primary method of using subversion soon. In my particular
implementation I need a superset of the features offered by the command
line client. The API provides me the tools to do that. I wouldn't have
spent as much time as I have getting the perl client bindings up to
speed if it wasn't so important.
> 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.
I'd say Greg Stein's comment here is an argument for making the changes
now. If we want to view things as a group then we might as well get the
pain overwith. While we're doing our soak time, why not spend some time
going to the various projects using subversion and trying to cordinate
updated versions of their program to match our APIs?
Looking at the votes we're going to have API changes betwene 0.35.0 and
1.0. So let's get the API stuff out of the way now.
I'd be more than happy to spend some time working on helping get some of
the other projects API issues dealt with. RapidSVN for example doesn't
seem to keep up with subversion at all. ISTR it went from a 0.29
compatable version to a 0.34 compatable version and within days 0.35 was
released and broke it again.
So we've already got projects that won't work with the existing releaesd
versions out there. It's going to take some special effort to see to it
that they get updated.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stabilization & number of changes
Posted by Greg Hudson <gh...@MIT.EDU>.
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
Re: stabilization & number of changes
Posted by Greg Stein <gs...@lyra.org>.
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)
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
Re: stabilization & number of changes
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jan 05, 2004 at 06:16:20PM -0500, Greg Hudson wrote:
>...
> (On every point except the date parser, there appears to be common
> ground. But on that one point, gstein is standing quite firmly in the
> way, and he does not appear to have followed up on his veto so far, so I
> am still quite steamed about it.)
It hasn't been all that long in the scheme of things, especially given the
mound of post-vacation email that has accumulated. I felt it most
important to get some votes recorded.
Properly and respectfully responding to your queries and describing my
reasons takes a lot more time. You don't deserve a flip answer, so I don't
want to give you one. I had hoped to have more time today, but that wasn't
in the cards. This evening... sure.
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
Re: stabilization & number of changes
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-01-05 at 14:35, kfogel@collab.net wrote:
> > I didn't ask to put off branching, but I'd like to see a
> > bit less reticence to fix API problems among the CollabNet crowd, since
> > that same crowd does not appear to have put much consideration into the
> > API before driving the stabilization process.
> The CollabNet developers put as much thought into APIs as anyone else.
> If we (I mean everyone, not some subgroup of developers) made poor API
> choices, then we made poor API choices.
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.)
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.
I'm not saying it's inherently wrong to think of the API as a
second-class feature of the 1.0 release and not worry too much about
it. perl clearly thinks of its C API that way and that doesn't seem to
have impeded it's popularity. But I would be happier if the people who
feel that way would not stand in the path of those of us who are trying
to maximize the likelihood that the 1.0 API is not tentative and won't
need incompatible fixing in the medium term.
(On every point except the date parser, there appears to be common
ground. But on that one point, gstein is standing quite firmly in the
way, and he does not appear to have followed up on his veto so far, so I
am still quite steamed about it.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org