[PATCH STABLE] revlog: add an experimental option to mitigated delta issues (issue5480)

Augie Fackler raf at durin42.com
Wed Jul 5 10:08:51 EDT 2017


> On Jul 4, 2017, at 23:07, Sean Farley <sean at farley.io> wrote:
> 
> 
> Augie Fackler <raf at durin42.com> writes:
>> 
>> I’ve grafted the commit to default, pushed a backout to stable, and merged with i18n. I’ll probably roll the release sometime this afternoon.
> 
> Since this process was a bit opaque to me, perhaps we could do a few
> things to clear it up for me (and hopefully others!) in the future:
> 
> - I think others need to actually weigh in for more of a consensus (I
>  believe Martin and I agreed it was fine for stable)

Indeed, there was some thinking on both sides, but the commit message itself notes that new features on stable are uncommon. Given that Greg and I both were uncomfortable, and I wanted to perform the release (which I'm about to start[0]), I didn't wait very long before getting things moved along.

> - Now, that I think about it the only list of things appropriate for
>  stable are here:
> 
>  https://www.mercurial-scm.org/wiki/TimeBasedReleasePlan?action=fullsearch&context=180&value=stable&titlesearch=Titles#Rules_for_code_freeze_and_stable_branch_commits
> 
> Can we get some clarification on things like this? I know I'd appreciate
> it :-)

I'd love to chat about it and try to clarify. This one felt like it was a bug fix that required significant new work (it's got a config knob!), and usually we bias towards putting those in a major release unless there's widespread impact for the bug[1].

Let me know if this helps - I agree we should try and clarify the handling of stable some. The situation is only going to get murkier once we tackle having an LTS release (which I'd still like to do.)

Thanks,
Augie

0: I meant to do it Monday or Tuesday, but life got in the way and it slipped to the start of a work day. :/

1: My understanding is that the bug in question results in prohibitive storage use if it happens, which is happening for one user that we know of. Given that we're two weeks from an rc release anyway, I'm not willing to risk 4.2.2 (which will, barring any LTS plans, be the last release to ever support 2.6) with this extra bit of churn.


More information about the Mercurial-devel mailing list