"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.
---------------------------------------------------------------------
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:29:21 CEST