Re: Subversion 1.5 Release decision?

On Thu, May 22, 2008 at 3:02 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "Mark Phippard" <markphip_at_gmail.com> writes:
>>> The more I think about it the more I prefer #2. I am not sure how we
>>> would do this technically. Create a 1.5.0-GA branch from the RC5 tag
>>> and then merge the select fixes we consider safe?
>>>
>>> I am going to do a closer review of what has been back ported since
>>> the RC5 change, but other than the API changes, I do not think any of
>>> them were critical for GA or show stoppers.
>>
>> So here is a follow-up. I looked through all of the post-RC5 merges
>> and grouped them. I am attaching text files for each of the groups.
>> Here is a summary though. I see only two backports that arguably
>> could use some more review if we wanted to consider them conservative
>> enough for a one-week soak.
>
> Oh, I don't think that any amount of a review makes a change more or
> less conservative/trivial.
>
> Hmmm. You came up with two; I came up with three, earlier.
>
> We agree on r31185 and r31218. But I also flagged r31186. Did you just
> overlook that one, or does it seem trivial to you?

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.

> I'm definitely more comfortable with the #2 plan, despite my earlier
> mail to Brane pointing out weaknesses in our documented soak policies.
> We're better off releasing what we soaked (modulo *truly* trivial fixes,
> which can be soaked for a shorter time, as per hacking.html).
>
>> I do not think either of these need to go into 1.5.0.
>
> Agreed.
>
>> I should point out that there is another one of these changes in
>> STATUS. I think we could ship 1.5.0 without this fix, but it does fix
>> a bug we have encountered ourselves.
>>
>> * r31059, 31060, 31061, 31075, 31151
>> Fix issue #3157, Merging a change from a path's natural history
>> creates self-referential mergeinfo
>
> Yes, I'm trying to review that one now, but finding it very hard to
> ascertain its correctness. (Not that there's anything wrong with the
> change, it's just an area of the code I have insufficient experience
> with.)
>
> It's hard for me to say with a straight face that I think including the
> #3157 group but *not* requiring a full soak for it is a good idea :-(.
> I'm sorry -- I want to ship as much as you do, but there's no way that's
> a trivial change, and it's also the kind where bugs are only likely to
> come out of the woodwork with extensive user testing.
>
> And Paul just said in IRC that he *still* has concerns about the fix,
> though he didn't go into detail...
>
> Given this, is it so important that it be in .0?

Sorry, I meant to include that. No, I do not think it needs to be in
.0. I was just saying that I think it is more significant, and
less-trivial, than the other two.

>> Of the fixes that I do not think need review, the ones I have
>> classified as API changes we would probably want to get into 1.5.0.
>> And then there is also the svnmerge.py improvements that I think ought
>> to go into 1.5.0. That fix is in the "conservative fixes" file.
>
> I think those are fine.
>
>> Given this, I think we should try to get some additional review for
>> the two revisions I have flagged, be conservative about what ELSE we
>> backport. And then make RC6 from the current branch + 1-week soak for
>> final release. We could also potentially try to back out the two
>> changes that need review if we do not feel they have received it.
>>
>> Looking at those fixes they both look like edge cases so I wonder how
>> much potential they have to cause unrelated regressions anyway.
>
> But if they're edge cases, they're less important to include...
>
> I know I'm see-sawing, sorry. But if we were to ship with all the
> highly-desired changes currently available, *including* the #3157 group,
> I really think that should restart a full soak period. I know I wavered
> before, but looking at the changes, it just seems like it's a bit much
> now.

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.

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org