"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?
> 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.
-Karl
---------------------------------------------------------------------
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:02:28 CEST