Freeze or no freeze?

Martin von Zweigbergk martinvonz at google.com
Tue Jul 24 17:23:26 EDT 2018


On Tue, Jul 24, 2018 at 2:21 PM Augie Fackler <raf at durin42.com> wrote:

>
>
> > On Jul 24, 2018, at 12:57, Martin von Zweigbergk via Mercurial-devel <
> mercurial-devel at mercurial-scm.org> wrote:
> >
> > The code freeze just started. I'd like to start a discussion about no
> longer having freezes.
> >
> > Some benefits of not having a freeze:
> >
> > * Patch authors won't have to wait so long for feedback and won't risk
> going as far in the wrong direction
> > * Review load gets spread out a little more evenly
> > * Those who don't particular care about running only released versions
> won't have to wait so long for new features and bug fixes to land on the
> default branch
> >
> > I'm personally affected by all those points, at least to some degree.
> I'm mentioning that just so my bias is clear.
> >
> > As I understand it, the reason we have the freeze is in order to
> convince people to test the release candidate and not a later version from
> the default branch. I believe it's effective in achieving that (I mean that
> I think most people do not instead run their own patched version). However,
> I'm not sure we would find that many fewer bugs if we queued patches for
> the default branch while the release candidate is out. It obviously happens
> that a bug from the stable branch gets fixed by patch to the default branch
> (and people testing on the default branch would thus not notice the bug on
> the stable branch), but my impression is that that is pretty rare.
> >
> > Thoughts? Were there other reasons for the code freeze that I missed?
>
> AIUI that's basically it. Is the suggestion that we keep landing things on
> default and merge stable into default as we go, basically?
>

Yes.


>
> I'm +0.5 on this - I won't fight for it too hard, but in general I think
> we're in a good enough place test-coverage wise that we're not finding
> major regressions during the freeze anymore. I'd be enthusiastic about
> trying this in the next cycle and if it doesn't go completely sideways we
> could stick with it.
>

Sounds like a good plan to me (obviously).


>
> >
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20180724/f71599d1/attachment.html>


More information about the Mercurial-devel mailing list