[QGIS-Developer] 3.10 hard freeze?

Nyall Dawson nyall.dawson at gmail.com
Mon Oct 14 16:28:20 PDT 2019

On Mon, 14 Oct 2019 at 19:35, Borys Jurgiel <lists at borysjurgiel.pl> wrote:
> Dnia poniedziałek, 14 października 2019 07:32:52 CEST Denis Rouzaud pisze:
> > Hi all,
> >
> > I had a PR tagged as frozen this morning.
> > I guess this is related to the concept of hard freeze. Can someone give
> > more information on soft vs hard freeze? Any what is accepted to be merged?
> "Two weeks before the release a hard freeze is initiated, after which only
> fixes to severe problems and regressions introduced after the feature freeze
> are allowed in." - I found it accidentally in [1] this weekend and postponed
> my PR for 3.10.1, apparently opening a Pandora's box...

To be honest, I think most people forgot about this. I did too, until
your comment prompted my memory!

> I'm not sure if all those PRs can
> be merged into 3.10.1, or should be rather considered new features?

If they are bug fixes, then they should definitely be merged for
inclusion in 3.10.1 as soon as the 3.10 release is branched. (Just
like we'd normally do with bug fixes and point releases)

> In the
> former case I wouldn't postpone all the release schedule, but if the latter,
> that unexpected freeze should be IMHO thoroughly reconsidered.

Well, it's not unexpected. We're just all forgetful people :D

I still think the original idea has many merits, and don't think we
should discard it because of initial teething problems. The situation
as I see it:

1. we've got one set of serious known regressions, due to the snapping
threading changes. There's an open PR which may resolve these
(https://github.com/qgis/QGIS/pull/31648), which still needs
reviewing, merging and widespread user testing before final release.
Or we can play it safe for 3.10.0 and revert the earlier threading
work, pushing it back for inclusion in 3.10.1. (playing it safe would
be my vote)

2. we've a bunch of open PRs for less critical issues, which, if we
are respecting the hard freeze as intended, should definitely be
delayed until 3.10.1

3. we should be pushing out a widespread call for user testing of the
"release candidate" (i.e. the nightly snapshot which happened after
hard freeze landed)

4. we need some policy about when a bug is considered critical enough
to break the hard freeze. (I'm pretty sure everyone considers their
own personal bugs as "critical", but again, if we are respecting the
hard freeze as original designed then it's only "oh my gosh we CANNOT
possibly push out a release with THIS in it!!!11!!" level bugs which
would be applicable)

1 & 3 need to be resolved ASAP, 4 can be discussed in a nice logical
manner during lead of up final release and after ;)


> Regards,
> Borys
> [1] https://www.qgis.org/en/site/getinvolved/development/roadmap.html#feature-freeze
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

More information about the QGIS-Developer mailing list