stabilize means STABILIZE (was: svn commit: rev 7961 - trunk/subversion/libsvn_wc)

On Wed, Dec 10, 2003 at 04:21:12AM +0000, Julian Foad wrote:
>...
> I checked in unclean, inconsistent code, and you pointed that out and I
> reverted it. Now we should separately reconsider the design questions:
>
> + Do we want to fix _any_ of the existing uses after closure?
>
> + Do we want to programmatically prevent _some_ uses after closure?

We're trying to stabilize and release 1.0. This kind of work appears to be
*very* contrary to that.

Think about it: you had to REVERT the change. What does that say? When was
the last time that happend? Maybe during development it happened here and
there, but it wasn't common. And now we're in the END GAME, and a commit
went in which was Not Right and had to be reverted.

Come on. Please stop this kind of thing. It isn't going to help us reach a
1.0 release with this happening.

Look: everybody agreed to staying on the trunk for the 1.0 release. That
means treating it with extreme frickin' care. If commits like this happen
even one more time, then we are going to HAVE to branch.

We can clean and fix and clean and fix and clean and fix for the next six
damn years. How about we stop and get 1.0 out the door instead? If you're
about to type 'svn commit' ask yourself: do we really need this? do our
users need this for 1.0? is this an improvement so fantastic that it
*must* go into the codebase? Does that APR -> svn_io change have to
happen? Do we have to fix that error message? Does the comment *really*
need to change? Most likely: no. Not at all.

Is there a memory corruption? Scalability problem? Crasher? Security
violation? Then yah. But how about posting a patch first? Maybe some
discussion? Maybe there are alternatives?

We're shooting for 1.0. Treat the trunk appropriately.

-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