On Mon, May 19, 2008 at 4:55 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "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.
Yes, I knew you said that but I had gotten a little confused by some
of your other comments where it seemed like you were evaluation what
to include on a commit by commit basis.
>> 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.
I should really probably read the archives before I make this point,
but I know we have had previous releases where 4-5 weeks into the
cycle we merged non-trivial fixes and did not do a full soak. I do
not want to open a debate on our policies, which I generally agree
with, but let's be honest here. If these fixes go into a 1.5.1 we
will release them with essentially no soak period at all.
> 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?
I wouldn't call it serious, more icky. I would say serious would be
something where it caused problems for merge. It sucks for log -g
users. I am also not sure how common it would happen. We have run
into it, but only on a couple of merges. Mike Pilato made a recipe
for creating the problem fairly easy. The only reason I think it
should go into 1.5.0 is ...
> Can't mergeinfo be edited?
Yes for merge, but no for the log -g/blame -g options. As Mike said,
this property is versioned and those commands operate on what happened
to the property in the history of the repository.
> 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 agree and I cannot really say whether this particular fix is more or
less likely to cause regressions compared to other fixes.
> 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.
Well FWIW, I think of the soak as being more important for our API
consumers than anyone else and changing the API at the last minute is
probably worse than trying to fix a bug.
>> 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.
Then I guess I'd be in favor of releasing 1.5.0 based off RC5 and get
the 1.5.1 queued up to be ready to go shortly thereafter (say 3-4
weeks later).
--
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 23:13:35 CEST