On Mon, 14 Oct 2019 at 19:35, Borys Jurgiel <li...@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 ;) Nyall > > Regards, > Borys > > [1] > https://www.qgis.org/en/site/getinvolved/development/roadmap.html#feature-freeze > > > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer