> -------Original Message-------
> From: Karl Fogel <kfogel_at_red-bean.com>
> Subject: Re: Subversion 1.5 Release decision?
> Sent: 22 May '08 12:29
>
> "Mark Phippard" <markphip_at_gmail.com> writes:
> > I put this one in the conservative-fixes.txt. I definitely think it
> > is trivial. It was a minor change, the rest was indentation mess-up.
> > Here is the log:
> >
> > r31186 | hwright | 2008-05-15 00:00:53 EDT
> > Changed paths:
> > M /branches/1.5.x/subversion/libsvn_client/merge.c
> > M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
> >
> > Merge r30746, r30747 from trunk:
> >
> > * r30746, r30747
> > Fix a minor merge range notification header bug.
> > Notes:
> > r30747 is just cleanup of some cruft that snuck in with r30746,
> > thus adhering to my "every commit should need a follow-up" ethos.
> > r30746 contains, like, one tiny *real* change, then a whole bunch
> > of bogus indentation changes that were supposed to be part of
> > r30748. Probably best to not fix that indentation during
> > backport, in case we later backport r30748.
> > Votes:
> > +1: pburba, markphip, cmpilato
> >
> > I am not saying this has to go into .0 either, just that I do not
> > think it needs more review.
>
> Sure. The question is also about soak time, not just about review.
>
> I was ignoring the whitespace changes; I'm talking about the change
> itself. And if it's so trivial, then why has it had a followup on trunk
> further modifying that same conditional? :-) See r31312, which has now
> also been nominated in STATUS.
>
> > So should we just back out the two changes we are concerned with?
> > Looking at what those two fixed, I still think they are not worthy of
> > a new soak if we included them. I agree about 3157, so I would say
> > just leave it out. I'd be OK with backing out the other two (or any
> > others). I am not sure we really need to.
>
> I'd prefer to back them out.
>
> > We need to be more conservative about what is getting back ported now
> > too, and just encourage people to move them to the approved section in
> > STATUS.
>
> Do we need to be more conservative about backporting? We have
> merge-tracking, let's use it. We can make a release starting from any
> tag or rev we want, merge stuff into it, etc. I don't see any need to
> slow down 1.5.x merging activity just because we're trying to make a .0
> release. If something gets the votes, let's merge it. *But* that
> shouldn't have any bearing on what gets released in 1.5.0.
Huh? We've *always* released from the tip of the 1.y.x branch. Releasing from something other than that seems like it would involve a bit more process than we currently use, but maybe the new features make that possible now. Personally, I'd rather not mess with additional release branches; if we don't want to include stuff that's already been merged, let's just back it out, cut the tarball, and then remerge it (and pray mergetracking works as advertised).
---------------------------------------------------------------------
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-22 21:37:13 CEST