Greg Hudson <ghudson@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
Received on Mon Jan 5 21:29:19 2004