Greg Stein <gstein@lyra.org> writes:
> > Well, no, please don't check in even tweaks like this -- unless you're
> > prepared to remember them, look for them in the new repository when it
> > goes live, and re-check them in if they're absent.
>
> When we are ready, the repository should be tagged and then commit access
> disabled. By definition, nothing can get in after that.
Yes, but that doesn't address the issue of changes coming in *while*
we're working on the release.
> > Because if you happen to check it in after we've rolled the dist
> > tarball and created the new repository, then your changes can't be
> > easily included without redoing the import and/or re-rolling the
> > tarball, which would of course imply re-testing it...
>
> Karl. You're being tweaky. Bill and I just discussed a *cast* and an extra
> #include to clear up warnings. There is zero problem checking them in.
Greg, I'm not being tweaky. Think about the process here. It doesn't
matter whether the changes are known to be safe; the issue is that
either a) a tarball might have to be rebuilt and put in the download
location *again*, or b) Bill would have to remember to reapply his
commits.
If Bill is confident that he'll do (b), then it's fine. But I don't
want to have to do (a), because once we get that thing built, I want
to go home, not sit here rebuilding dists, which takes time even if
they don't need to be tested.
...And they do need to be tested, anyway; distribution paranoia has
paid off for me too many times in the past to disregard it now.
> Go look at some of the other commits if you want to find problems.
?
> Now that you've delayed his checkin, yes: maybe they will miss.
I think Bill knows how to handle this; certainly he hasn't complained
about it.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:36 2006