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

Tuukka Turunen tuukka.turunen at qt.io
Fri Feb 7 12:01:46 CET 2020


In practice we also do have some slack in the schedule exactly to allow sorting everything out. Unfortunately it is often not long enough, but we have delay in getting the alpha out. I do agree that we should include the features that are ready in time - and I do not think there are many who would disagree. 

One thing that tends to happen is the last minute pile up of commits at or near the FF time. While understandable, the more we can do to avoid this the more likely it is to have successful integrations. 

Especially with Qt 6 we need to make sure as many items as possible are not piling up just at the FF date. Maybe we should set a bit earlier FF date for the modules most others depend upon? Or other similar phasing instead of a day when everything needs to be in. 



´╗┐On 7.2.2020, 9.59, "Releasing on behalf of Eskil Abrahamsen Blomfeldt" <releasing-bounces at qt-project.org on behalf of Eskil.Abrahamsen-Blomfeldt at qt.io> wrote:

    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...
    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
    The Future is Written with Qt
    Releasing mailing list
    Releasing at qt-project.org

More information about the Releasing mailing list