On Sat, May 17, 2008 at 8:49 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> Mark Phippard <markphip_at_gmail.com> writes:
>> Make an rc6 soon so that we can give it a couple weeks before release?
>
> ? Well, that doesn't really address the question I'm asking... We
> already have a date on which to roll rc6, and while I've no objection to
> adding an extra week to its soak time, I don't think it's really
> necessary either.
What is the date? I was not aware we had set one. I was thinking if
make an RC6 it will about a week from now. I was just saying let's do
the RC6 now so that we can have an extra week with it running on our
server and elsewhere.
> The question is just what changes to include in rc6. For example, I'd
> be very happy for 1.5.x-r31159-r31179 branch changes (merged in r31218)
> to simply wait until 1.5.1. That way they'd get a full soak in a later
> RC, and of course testing on trunk as well that whole time.
>
> Regarding the other two changesets I listed (merged in r31186 and
> r31185), a good plan would be for us to figure out what harm would come
> from letting them wait until 1.5.1. If we decide they can wait, then
> IMHO they should; if we decide they really need to be in in 1.5.0, let's
> at least give give them extra review, so that on top of the one-week
> soak they've had more brain time as well.
But would you propose we "un-merge" the ones we are not sure of? On
some of the ones you are concerned with, I am mostly concerned if they
cause unrelated regressions. Especially since that has plagued us
during the RC process. That said, I have concerned about some of the
changes still in STATUS:
* r31059, 31060, 31061, 31075, 31151
Fix issue #3157, Merging a change from a path's natural history
creates self-referential mergeinfo
I would like to see this in 1.5.0 because once the "bad" mergeinfo is
created you cannot fix it. Note, that the mergeinfo is only bad for
log -g, not merge itself. But we have run into this problem on our
own repository, as well as via a user testing the RC. So we know it
is real.
Then there is this one:
* r31243, r31246, r31249, r31250, r31251, r31271
Fix issue #3200, API Ickiness: svn_client_ctx_t shouldn't carry
"extra revprops"; the svn_client APIs should
Notes:
If we *don't* backport this in 1.5.0, we need to undo the changes
or otherwise rework them to use newly-revved svn_client APIs.
This is not quite finished -- need feedback from Ruby, Perl, and
JavaHL bindings maintainers.
Since it is fixing the API it has to go into 1.5.0 or pretty much just
be undone. I want to be against this change as not being worth the
risk, but I suspect the API ickiness in this case is probably worth
fixing.
What if we just pushed to get STATUS clean and do an RC6 and give it
two weeks for GA?
--
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
Received on 2008-05-19 16:43:05 CEST