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

[Edward Welbourne]

On 05.02.2020 11:50, Edward Welbourne asked:
>>>> 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 ?

Eskil Abrahamsen Blomfeldt (keskiviikko 5. helmikuuta 2020 13.06) replied:
>>> 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.

Makes sense.  See below.

On 05.02.2020 13:04, Jani Heikkinen wrote:
>> 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...

Eskil Abrahamsen Blomfeldt (7 February 2020 08:58)
> You are looking at this from a very different perspective than me,
> which is totally understandable.

Indeed - still, let us all try to see this from each others'
perspectives.  That gives a better chance of finding a resolution we can
all be happy with.

> As a developer of the product, I want a deadline for when I should
> have my feature finished. If the deadline is "maybe one month before
> the feature freeze, maybe one week, who knows it kind of depends on
> whether the CI system is acting up and what other changes your fix
> happens to be bundled with", then that makes it impossible to plan
> anything.

On the other hand, if a change that should be subject to FF turns out to
have problems that mean it wasn't actually ready in time, how severe can
those problems be and *not* imply that we should keep that feature out ?

This week, we've given special dispensation for things that were delayed
due to minor problems that were known at the time of FF.  That seems a
reasonable level of flexibility in an otherwise hard FF.  If a change
that seemed ready for merge last Friday turns out to cause problems that
weren't anticipated then, unless they are promptly resolved and low-risk
(given the previously accepted change), it makes sense to block that
change until the next release - otherwise, the release process becomes
chaos, as it voids FF's rule about what's in and what's out.

[snip]

> The next one will be coming after six months in most cases (Qt 5.15 is
> special of course). This is a pretty long time. But more importantly,
> expecting every single developer in the Qt community to internalize
> the flakiness of the CI system or the risk that your change may be
> rejected because it happened to be bundled with a broken change is the
> wrong angle in my opinion.

I don't think anyone is currently standing for that position: if the
only thing that's kept a change out is CI failure, or being staged
alongside someone else's broken change [0] on the day of FF, then I
think we're all in agreement that the change "made it in time".  On the
other hand, the broken change whose premature staging blocked others'
changes from getting integrated *should* be subject to scrutiny - if it
can be fixed safely, satisfactorily and promptly then fine, but if it's
going to delay other changes with further integration failures then we
should be ready to Just Say No to it after the FF deadline passes.

[0] and you know which change I'm thinking of, Eskil.
I'm happy to see it got fixed up quickly ;^>

We presently have (only semi-formally) a process that requires API
changes to be in by the FF deadline but provides for community
(i.e. this list) approval of stragglers, when we are confident they are
unlikely to harm stability or schedule.  That seems workable.

	Eddy.