[QGIS-Developer] 3.10 hard freeze?

[Borys Jurgiel]

Dnia wtorek, 15 października 2019 01:28:20 CEST Nyall Dawson pisze:
> 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:

I guess we share the same (or almost the same) point of view: everything than 
can wait for 3.10.1 should be postponed and merged 4 rather than 2 weeks 
before release (btw. it's not clearly stated, but I assume the hard freeze 
also applies to point releases - otherwise it won't make much sense)

It was more a question from my side if there are ready-to-merge PRs that can't 
be assumed point release fixes. In that case we'd have a problem to resolve 
and the lack of announcement was a partial reason.

It seems nobody complains, so it's not the case ;)

> 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)

It was my main concern, and feel the same.

> 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

Exactly.

> 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)

+1. I'll do it here in Poland today. We always have problems with encouraging 
people to be early testers, so let's try harder.

> 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)

No strong opinion here. If we apply the strict rule to every point release, we 
have two weeks for bugfixes and two weeks for testing whether they didn't 
break anything. I'm afraid that time may be lost, as who uses LTR nightlies? 
;)

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

Ok, let's go!

Borys