On Wed, Dec 10, 2003 at 10:53:56AM -0500, Greg Hudson wrote:
> On Wed, 2003-12-10 at 04:10, Greg Stein wrote:
> > 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.
>
> It has happened from time to time. It is rarely foreseen by the person
> making the commit.
Certainly. I would doubt that anybody commits with the intent to revert :-)
> > Look: everybody agreed to staying on the trunk for the 1.0 release.
>
> I apologize for contributing to confusion here, but... no, we didn't. I
Gah... okee dokee. I missed the resolution here. Regardless of where it
happens, the "branch point" is still an arbitrary point in time. The trunk
today has *very* little difference from the branch next week. A commit
today isn't "magically safer" because it occurred now rather than
post-branch. If we chose to branch yesterday or today, then would any
given commit suddenly morph into "oh, well that is unsafe and shouldn't
happen". A commit that is made will introduce an absolute amount of
potential for breakage. At this point in the lifetime of SVN, those
amounts should be as minimal as possible.
> only wanted to stabilize on the trunk because I thought it would take
> six months (and even then, I wanted to branch at the end of that
> period). We agreed to branch, because the stabilization period will be
> short, but I think we're going to do that just after 0.35, which is
> beta. Right now we're still in alpha.
Um. "we're still in alpha [so we're still free to commit]" doesn't really
work here. Our notion of alpha is awfully strict, and the simple fact is
that "beta" (for svn) is "we don't think we're going to change the code
any more", more popularly known as "1.0 release candidate".
Within those guides, the notion that an alpha can suddenly make certain
types of commits somehow "safe" isn't very supportable.
>...
> We're still in alpha,
And I think that is an arbitrary label, and our usage doesn't really
confer the notion of "so these changes are okay".
> and none of the changes you're talking about have
> been destablizing. (Even Julian's didn't break anything, as far as I
> know, although it certainly made the code unclean.)
Agreed. We're talking about potentials here. Each commit has a potential.
We caught this one. How about the recent change to how SSL errors are
tracked. Some basic data structures changed. Was that one safe? Sure, I
bet it was (given my cursory review of it). What about the next change?
I'm not trying to call out a problem with Julian's work or even that one
commit which needed to be reverted. To me, it seems that the notion of
"let's wrap this up and call it 1.0" just hasn't sunk in.
If all commits stop, and attention is turned towards the commits which
*have* to go in, then we'll get good eyeballs on those commits. But while
a dozen commits are occurring every day, it doesn't help the focus.
> > We're shooting for 1.0. Treat the trunk appropriately.
>
> We're not really at that point yet. There are certainly a lot of
> changes which wouldn't be appropriate for late alpha, but cleanups are
> still fine.
I disagree. :-) We don't have to agree, and I'm just one voice, but I
seriously think it *is* time to just stop committing unless it can be
shown that the change is *very* necessary.
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
Received on Thu Dec 11 08:36:58 2003