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

[Eskil Abrahamsen Blomfeldt]

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

Hi,

You are looking at this from a very different perspective than me, which 
is totally understandable.

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.

If we estimate, based on statistics, that it will take one month to get 
features in, then we should set the feature freeze one month earlier. If 
we think it will take one week, then we should set it one week earlier. 
At least we should give people a specific date and guarantee that if 
they make it in time for this, their change will be in the next release. 
If this is one month before the actual feature freeze, then so be it. If 
it takes that long to get a change in, then definitely should be very 
visible to everyone, including the stake-holders who depend on features 
being released when we say.

If it turns out that we miscalculated the estimate, then this should 
just cause a delay to the release. It shouldn't cause us to make a 
release containing a random set of features based on whoever won the 
lottery this time.

I understand that your responsibility is making the release on time, and 
late submissions make this difficult, but the way to solve this is to 
add the extra slack between the feature freeze and the point where we 
can start stabilizing to the release schedule. If we see that changes 
that are staged at the freeze date consistently take between 1 day and 1 
week to merge because we have broken systems or because so many people 
stage their changes at the same time, then that means we have to extend 
the period between freeze and release by one week.


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

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. We would just be distributing the responsibility of 
analyzing our release systems to hundreds of people instead of doing it 
once, as part of the release planning.

So if you know how long it will typically take for a change to get in, 
then why not give people the actual date they should target in order to 
be sure to get their changes merged? And if our estimates are wrong, 
then we should own that mistake, instead of telling developers that 
their changes have missed the deadline because we are unable to provide 
working and predictable systems.

The current message to developers is: "You should commit your changes at 
some unspecified time before feature freeze, because our systems are 
buggy and also designed in a way that cannot guarantee that correct 
changes are merged in any given time even if everything works as 
intended. We don't know how long before the freeze you should do this, 
so hopefully you can find out yourself?"

In my opinion this is chaos, and a lot worse than having a week's delay 
on a feature release.

-- 

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
eskil.abrahamsen-blomfeldt at qt.io
+47 938 85 836
http://qt.io
https://twitter.com/eskilblomfeldt

The Future is Written with Qt