[Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Jani Heikkinen]

> -----Original Message-----
> From: Eskil Abrahamsen Blomfeldt <Eskil.Abrahamsen-Blomfeldt at qt.io>
> Sent: keskiviikko 5. helmikuuta 2020 13.06
> To: Edward Welbourne <edward.welbourne at qt.io>; Jani Heikkinen
> <jani.heikkinen at qt.io>; Lars Knoll <lars.knoll at qt.io>; Volker Hilsheimer
> <volker.hilsheimer at qt.io>
> Cc: Qt development mailing list <development at qt-project.org>;
> releasing at qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
> 
> 
> On 05.02.2020 11:50, Edward Welbourne wrote:
> > Jani Heikkinen (5 February 2020 06:42)
> >> Why this is so important that we should get the exception & go in after
> FF?
> > Do we allow changes approved before feature freeze to get past the
> > Coin hurdle, even if that happens after FF ?  How much fixing of the
> > change (if it turns out to have problems integrating) is acceptable,
> > before we declare that it's no longer the change that was approved in time
> ?
> 
> 
> If the change is ready and approved by the time of feature freeze and only
> delayed by CI problems, failures from other changes in a batch, or the
> awkwardness of our dependency structure, I think it has to be acceptable to
> merge after the freeze. Otherwise feature freeze becomes a lottery where
> the features in a given release is based mostly on chance.

By default we shouldn't put any new features in after FF, not even those which were approved early enough. Not respecting the freeze date was one of biggest reasons why we failed to keep the release schedule with earlier releases. And after we started to be much tighter with the freeze we have been much better to keep the schedules as well...

> The slack to accommodate these intrinsic delays need to be in the release
> plan in my opinion, and not in each developer's individual plan for merging
> their changes.

I have to disagree. Everyone knows that there is flakiness/problems in integrations and so on changes has to be ready early enough so that there is still time to pass the CI. That's why FF date is agreed & informed quite early & there is several heads-up telling it is coming closer...

We are doing time based releases so if new feature misses the deadline there will be next one coming after few months. It might be quite long time for unique feature but on the other hand it isn't really that long... Our goal is to cut the schedule between FF and final release, not reserving more time there. Ok, currently there is of course some buffer in; Release plans are based on previous releases and realized schedules there. But we should be able to develop our ways of working & our release systems so that we can make that time much shorter. That way we could get more time to develop new features. 

br,
Jani