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'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?
Yes, we definitely want to hold off on the #3157 group, I just found
some new problems with that fix while working on another issue.
Mergeinfo for subtrees is not handled correctly in some cases (the
merge test we have for this issue is a bit too simplistic). Changing
my vote on that group right now.
Paul
---------------------------------------------------------------------
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 22:11:12 CEST