Hi all, I am really confused about the hard freeze period, probably because I am not able to explain it to anyone. Some questions:
- is there any place where the hard freeze is documented for coders and users? - What is the expected benefit if we don't get real life testers focused on testing? - Isn't it a Release Candidate version we-cant'-say-its-name ? Why so? - It seems to bring a lot of confusion between. It can cascade delays for backports to previous LTR, if we postpone fixes, then we miss a point release time frame, that sounds really strange to me. - I didn't see any public announcement, so I doubt we get more tester now than before the hard freeze tag. Did I miss something? At this point, it doesn't look like a 'teething' problem to me. I really start thinking we are trying to invent something that does not exists somewhere else. We do that to try to consolidate our fixes, which is a very valid reason. While the attempt is nice, I think the real issue is that we lack beta testers. Shouldn't we rediscuss of beta / RC releases with installers, together with public annoucement. It is more packaging and communication work, but I thinks this is where the most efficient efforts rely. I really miss a clear vision to be able to advertise it to our funders. We are ni hard time already just explaining the roadmap and the need for them to get in sync with it. The more complicated system we build, the more they tend to fall back to just "wait" other test the future LTR versions for them. I am really concerned because I in my whole country, I identify at max 2 GIS administrators involved in testing developpement versions. I'd appreciate any effort of explaining the rationales and how-to-use of this hard freeze thing. Regards Régis Le jeu. 17 oct. 2019 à 09:39, Nyall Dawson <nyall.daw...@gmail.com> a écrit : > > On Thu, 17 Oct 2019 at 17:35, Julien Cabieces > <julien.cabie...@oslandia.com> wrote: > > > > > > Hi all, > > > > > 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) > > > > Fair enough, if this work can land in 3.10.1, I will revert the initial > > commit and push it back for 3.10.1 inclusion. > > > > I think I misunderstand the frozen label, I thought it was to delay > > merging in 3.12, not in 3.10.1 ? > > It's used that way for features -- but otherwise it just means "don't merge!" > :) > > Nyall > _______________________________________________ > 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