On Wed, May 28, 2008 at 05:58:14PM -0400, Mark Phippard wrote:
> On Wed, May 28, 2008 at 5:22 PM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
> > As simple as this change might be, it breaks one of the getopt tests. The getopt tests are one of the only tests really matching the actual
> > string content character per character. I know these tests are overly strict, but while we have them I propose you run at least those
> > before you commit a text change inside the code.
>
> And as you said in the other email, why are we doing direct commits to
> the branch, without going through STATUS or even a dev@ email, right
> before we are about to make the release?
Shouldn't we immediately back out r31503 and r31506, both of which were
directly committed to 1.5.x without being voted for in STATUS?
Because what's the point in having STATUS if people don't use it?
http://subversion.tigris.org/hacking.html#release-stabilization
clearly says:
Core code changes, of course, require voting, and restart the
soak or test period, since otherwise the change could be undertested.
Both changes committed to 1.5.x fall into the 'core code changes'
category, one actually broke a test.
I'm not sure whether *all* changes have to go through trunk first,
but so far I haven't seen any change not going through trunk.
Please enlighten me if I'm wrong on this one.
I personally think having changes go through trunk first is very,
very valuable. Because a consistent direction of the flow of changes
we make helps everyone understand what's happening. Of course,
this excludes trivial release-specific stuff like setting version
numbers on a branch, but other than that I don't see any reason why
a change should not enter our code base through trunk. It will trickle
down into a release branch eventually if it needs to.
Stefan
- application/pgp-signature attachment: stored
Received on 2008-05-29 10:44:19 CEST