"Mark Phippard" <markphip_at_gmail.com> writes:
> 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.
Oh, I was referring to Hyrum's mail from last Wednesday, this one:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=138591.
He wrote:
> RC 5 was released on May 5, so I plan on rolling and posting the
> next (and hopefully final!) release candidate on May 23-24. If all
> goes well, whatever makes it into that RC will be in 1.5.0-final;
> they will share the same magic revision. Fixes which don't make it
> into RC 6 will be postponed to 1.5.1, which I anticipate releases
> 1-2 months after 1.5.0, pending demand.
> 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:
No un-merging necessary. Like I said, we have a choice of whether to
branch the next RC from the previous RC's tag or from the tip of the
current branch.
> What if we just pushed to get STATUS clean and do an RC6 and give it
> two weeks for GA?
Hmm, well, so we just ditch the original intent of the four-week soak?
We allow trivial/obvious changes to go in without restarting the soak.
But the guidelines (which IMHO are good) are pretty clear that what gets
released has to be basically what was soaked for four weeks. We seem to
be drifting away from that, and more by accident than on purpose.
When someone nominates a change for backport in the "1.5.0" section of
STATUS, that doesn't mean that change has to go into 1.5.0. It just
means that if we're re-starting the full soak anyway, then that change
might as well go in. But if we're not restarting the full soak, then
it's an open question whether the change can wait till 1.5.1 or not --
it really depends on the individual change.
You mentioned two that were of special concern:
> * 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.
That sounds pretty serious. But is it absolutely necessary that it go
in? Can't mergeinfo be edited? How often is this likely to happen
anyway? If it waited for 1.5.1, would that be a disaster? We can't
keep folding in serious bugfixes and then pretending they aren't exactly
what our soak time is intended to soak.
I'm reviewing the mergeinfo-related changes in STATUS and the ones
merged since 1.5.0-rc5 (see r31218, r31186, r31185). From a high-level
appraisal, it does look like some of those cannot be considered
"trivial", though.
We really need to focus on the fact that the point of a soak is that to
release the thing that was soaking, not some other thing that is
somewhat related. The hacking.html guidelines are clear on this, and we
wrote them that way for a reason. I'm reluctant to revise the process.
If we are going to revise it, let's please do it consciously :-).
> * 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.
Sure, this was just an API untwisting, not a "real" code change. As
long as we have enough eyeballs on it, I think there's little real risk
in letting it in with just a one- or two-week soak.
> What if we just pushed to get STATUS clean and do an RC6 and give it
> two weeks for GA?
Mrm. <squirms uncomfortably> See comments above.
---------------------------------------------------------------------
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 22:55:32 CEST