On 5/29/08, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
You're not wrong. Going through trunk first makes sure all changes end
up in all versions beyond 1.5. The only time a change can be committed
to a branch (but never directly) is when the code has been removed or
rewritten on trunk.
> 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.
Exactly. A clear flow of changes also guarantees future quality of the
software as described above.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-29 11:06:57 CEST