On 05.02.2020 13:04, Jani Heikkinen wrote: > >> -----Original Message----- >> From: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfe...@qt.io> >> Sent: keskiviikko 5. helmikuuta 2020 13.06 >> To: Edward Welbourne <edward.welbou...@qt.io>; Jani Heikkinen >> <jani.heikki...@qt.io>; Lars Knoll <lars.kn...@qt.io>; Volker Hilsheimer >> <volker.hilshei...@qt.io> >> Cc: Qt development mailing list <development@qt-project.org>; >> releas...@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-blomfe...@qt.io +47 938 85 836 http://qt.io https://twitter.com/eskilblomfeldt The Future is Written with Qt _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
