Re: [Development] Proposal: let's change the release schedules a bit
Volker Hilsheimer via Development wrote: > But for the release team, the busy time is shortly before, and > significantly after the freeze. So from that perspective, having the > feature freeze either significantly before the summer break, or > afterwards, makes most sense. They are the ones most impacted. > > So, if Jani and the team believe that their work will be made easier by > moving the feature freeze to be after the holidays, then let’s do that. If > we find out that it causes problems that outweigh the benefits, then we > can adjust again based on that experience. So you think it makes sense to inconvenience dozens of developers for the convenience of a handful release managers? Having only contributed small patches to Qt so far, I do not have a personal preference for the release schedule, but the way you are weighing the tradeoffs looks very odd to me. Kevin Kofler -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: let's change the release schedules a bit
Indeed, summer holidays are not the same for everyone, and it’s no the same every year. Berlin has school summer holidays mostly in August this year, after having them mostly in July last year, and even a bit in June already in 2021. From my personal perspective - in spite of living in Norway where the country shuts mostly down during July, I like to take my holidays in August as that’s when my family in southern Germany has their break - having time to finish features, or to work on small features, during the quiet time in July sounds lovely. In theory it is possible for us to plan our feature development work in such a way that it’s done before we take a break, just as much as it’s evidently possible to get done before feature freeze. And while we probably have all experienced that our plans didn't survive first contact with real life, we always have options: perhaps someone else that was involved in the work is available to push it over the finishing line; and if not, then we can always postpone the feature, or ask for an exception. Perhaps the slow time during summer allows those parts of feature development work to happen that is now often done after feature freeze (such as documentation). Parkinson’s Law probably holds, no matter what defines the allotted time - someone's personal holidays, or project level feature freeze. But for the release team, the busy time is shortly before, and significantly after the freeze. So from that perspective, having the feature freeze either significantly before the summer break, or afterwards, makes most sense. They are the ones most impacted. So, if Jani and the team believe that their work will be made easier by moving the feature freeze to be after the holidays, then let’s do that. If we find out that it causes problems that outweigh the benefits, then we can adjust again based on that experience. Volker On 6 Feb 2023, at 12:15, Tuukka Turunen via Development wrote: Hi, We have not yet concluded about Jani’s proposal for adjusting the feature freeze and release timing: https://lists.qt-project.org/pipermail/development/2022-December/043380.html The original proposal was: ”… release minor releases in April and October, that would allow us to move FF also after the holidays: So FF for April release would be in January and FF for October release would be in August.” We should make the decision soon to set the dates for Qt 6.6 release. Do we keep the current approach or go forward with extending the Qt 6.6. feature freeze to be in August instead of June? Yours, Tuukka From: Tuukka Turunen Date: Wednesday, 14. December 2022 at 11.44 To: Volker Hilsheimer , Jani Heikkinen Cc: development@qt-project.org Subject: Re: [Development] Proposal: let's change the release schedules a bit Hi, One of the main problems we face every time with the feature freeze is a lot of changes coming in just before the deadline. While this is quite natural as such, it does also cause some amount of instability and problems in getting the full integration test round completed regularly. There are many ways to tackle this issue and a lot of things have already been done (such as introducing a new freeze point for platforms/configurations in CI before the FF). Having the FF date just before a major holiday period is one item that possibly increases the instability. Not everyone is on vacation at the same time and especially during the summer different countries tend to have a bit different general preferences for the primary holiday period. Having the FF in January instead of December and August instead of June would likely reduce the number of changes coming in just before the deadline. Spreading the changes more evenly in the feature development timeline makes it easier to keep integration test rounds passing regularly. Yours, Tuukka From: Development on behalf of Volker Hilsheimer via Development Date: Thursday, 8. December 2022 at 14.03 To: Jani Heikkinen Cc: development@qt-project.org Subject: Re: [Development] Proposal: let's change the release schedules a bit For me, the argument that Eddy makes is very strong: a milestone or deadline right after holidays has the potential of ruining those holidays, without giving any meaningful extra time to get features done. Releases of operating systems have some relevance: new macOS and Windows versions have in recent cycles happened around March/April and October/November. But even if we try to have the Qt release shortly after those to claim quick support, in reality it would probably be “technology preview” status anyway, knowing how much time it takes to make new CI configurations significant. And TP status can just as well be achieved based on beta and preview versions. Linux distro cycles are more relevant to align with as we are upstream, but in practice I’d expect more practical value in having the first or second
Re: [Development] Proposal: let's change the release schedules a bit
Hi, We have not yet concluded about Jani’s proposal for adjusting the feature freeze and release timing: https://lists.qt-project.org/pipermail/development/2022-December/043380.html The original proposal was: ”… release minor releases in April and October, that would allow us to move FF also after the holidays: So FF for April release would be in January and FF for October release would be in August.” We should make the decision soon to set the dates for Qt 6.6 release. Do we keep the current approach or go forward with extending the Qt 6.6. feature freeze to be in August instead of June? Yours, Tuukka From: Tuukka Turunen Date: Wednesday, 14. December 2022 at 11.44 To: Volker Hilsheimer , Jani Heikkinen Cc: development@qt-project.org Subject: Re: [Development] Proposal: let's change the release schedules a bit Hi, One of the main problems we face every time with the feature freeze is a lot of changes coming in just before the deadline. While this is quite natural as such, it does also cause some amount of instability and problems in getting the full integration test round completed regularly. There are many ways to tackle this issue and a lot of things have already been done (such as introducing a new freeze point for platforms/configurations in CI before the FF). Having the FF date just before a major holiday period is one item that possibly increases the instability. Not everyone is on vacation at the same time and especially during the summer different countries tend to have a bit different general preferences for the primary holiday period. Having the FF in January instead of December and August instead of June would likely reduce the number of changes coming in just before the deadline. Spreading the changes more evenly in the feature development timeline makes it easier to keep integration test rounds passing regularly. Yours, Tuukka From: Development on behalf of Volker Hilsheimer via Development Date: Thursday, 8. December 2022 at 14.03 To: Jani Heikkinen Cc: development@qt-project.org Subject: Re: [Development] Proposal: let's change the release schedules a bit For me, the argument that Eddy makes is very strong: a milestone or deadline right after holidays has the potential of ruining those holidays, without giving any meaningful extra time to get features done. Releases of operating systems have some relevance: new macOS and Windows versions have in recent cycles happened around March/April and October/November. But even if we try to have the Qt release shortly after those to claim quick support, in reality it would probably be “technology preview” status anyway, knowing how much time it takes to make new CI configurations significant. And TP status can just as well be achieved based on beta and preview versions. Linux distro cycles are more relevant to align with as we are upstream, but in practice I’d expect more practical value in having the first or second patch release in a distro. So in summary, I don’t think any of those need to have a strong influence on our .0 release timing. What I don’t quite understand is why a long beta period is a problem. We get valuable feedback from community and customers during that, and I vaguely remember some reports of regressions coming in pretty late in the process, just before or even after the release candidate. I don’t know whether those reports came in late because users wait until things look almost ready (i.e. RC available), or because it simply takes time before enough users try out a beta. In the former case, a longer stabilization cycle makes no difference; in the latter case, we should rather make it longer. Perhaps we have some data on that (how do download figures develop compared to tickets in JIRA reported against preview versions), but I haven’t seen anything that I’d consider conclusive. And without knowing, I don’t see much value in trying to optimize things either way. Eddy’s concern on the other hand is very tangible. Volker > On 7 Dec 2022, at 12:48, Jani Heikkinen via Development > wrote: > > Hi! > >> Jani: what is the problem with that calendar interval's present length ? > We need ~13 weeks (real working time) from the feature freeze to the final > release. Currently we have holidays during that period and so on we need to > reserve much longer calendar time for that. E.g. with Qt 6.5 this time is > planned to be a bit more than 15 weeks and with Qt 6.4 it was a bit more than > 16 weeks. > For me this hasn't been a problem at all but I have heard some other opinions > as well; someone wants to finalize new things during holidays and someone > isn't that much in holiday e.g Christmas time. For those this would give few > weeks extra implementation time between the releases... > >>> I would sooner move the schedule half a month earlier - Nove
Re: [Development] Proposal: let's change the release schedules a bit
Tuukka Turunen (14 December 2022 10:44) wrote: > One of the main problems we face every time with the feature freeze is > a lot of changes coming in just before the deadline. That's how deadlines work. > Having the FF date just before a major holiday period is one item that > possibly increases the instability. Not everyone is on vacation at the > same time and especially during the summer different countries tend to > have a bit different general preferences for the primary holiday > period. All of which, to me, is a case for moving the FF a little *earlier*, to ensure it is robustly before the holiday for (as near as we can hope to attain) everyone. > Having the FF in January instead of December and August instead of > June Your point about different places having their holidays at different times makes August a very bad choice: it is *not* after the holidays - for at least some countries it *is* the holidays. > would likely reduce the number of changes coming in just before > the deadline. Spreading the changes more evenly in the feature > development timeline makes it easier to keep integration test rounds > passing regularly. I do not think this would spread the changes more evenly. Reducing the number of changes that make it in time for feature freeze won't change how unevenly they arrive, it'll just change when the mad rush happens. And putting the FF after some people's holidays and slap bang in the middle of other folk's holidays (at least for the summer one) would cast an ugly shadow over those holidays. Moving a week or three earlier would be better than trying to land after the holidays and instead landing in the midst of them, Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: let's change the release schedules a bit
Hi, One of the main problems we face every time with the feature freeze is a lot of changes coming in just before the deadline. While this is quite natural as such, it does also cause some amount of instability and problems in getting the full integration test round completed regularly. There are many ways to tackle this issue and a lot of things have already been done (such as introducing a new freeze point for platforms/configurations in CI before the FF). Having the FF date just before a major holiday period is one item that possibly increases the instability. Not everyone is on vacation at the same time and especially during the summer different countries tend to have a bit different general preferences for the primary holiday period. Having the FF in January instead of December and August instead of June would likely reduce the number of changes coming in just before the deadline. Spreading the changes more evenly in the feature development timeline makes it easier to keep integration test rounds passing regularly. Yours, Tuukka From: Development on behalf of Volker Hilsheimer via Development Date: Thursday, 8. December 2022 at 14.03 To: Jani Heikkinen Cc: development@qt-project.org Subject: Re: [Development] Proposal: let's change the release schedules a bit For me, the argument that Eddy makes is very strong: a milestone or deadline right after holidays has the potential of ruining those holidays, without giving any meaningful extra time to get features done. Releases of operating systems have some relevance: new macOS and Windows versions have in recent cycles happened around March/April and October/November. But even if we try to have the Qt release shortly after those to claim quick support, in reality it would probably be “technology preview” status anyway, knowing how much time it takes to make new CI configurations significant. And TP status can just as well be achieved based on beta and preview versions. Linux distro cycles are more relevant to align with as we are upstream, but in practice I’d expect more practical value in having the first or second patch release in a distro. So in summary, I don’t think any of those need to have a strong influence on our .0 release timing. What I don’t quite understand is why a long beta period is a problem. We get valuable feedback from community and customers during that, and I vaguely remember some reports of regressions coming in pretty late in the process, just before or even after the release candidate. I don’t know whether those reports came in late because users wait until things look almost ready (i.e. RC available), or because it simply takes time before enough users try out a beta. In the former case, a longer stabilization cycle makes no difference; in the latter case, we should rather make it longer. Perhaps we have some data on that (how do download figures develop compared to tickets in JIRA reported against preview versions), but I haven’t seen anything that I’d consider conclusive. And without knowing, I don’t see much value in trying to optimize things either way. Eddy’s concern on the other hand is very tangible. Volker > On 7 Dec 2022, at 12:48, Jani Heikkinen via Development > wrote: > > Hi! > >> Jani: what is the problem with that calendar interval's present length ? > We need ~13 weeks (real working time) from the feature freeze to the final > release. Currently we have holidays during that period and so on we need to > reserve much longer calendar time for that. E.g. with Qt 6.5 this time is > planned to be a bit more than 15 weeks and with Qt 6.4 it was a bit more than > 16 weeks. > For me this hasn't been a problem at all but I have heard some other opinions > as well; someone wants to finalize new things during holidays and someone > isn't that much in holiday e.g Christmas time. For those this would give few > weeks extra implementation time between the releases... > >>> I would sooner move the schedule half a month earlier - November FF for >>> February release, May FF for August release - and accept the calendar >>> interval between the two. > Unfortunately this isn't good option; finalizing the "summer" release would > be done during summer holiday season and it won't work. For winter release > this could work... > > And please note: I am not proposing to move Qt 6.5 FF; It will stay 9.12.2022 > as planned. But this would be something for Qt 6.6 ->. But like I wrote above > this isn't anyway mandatory for me, just a proposal. If most of us prefer the > existing frame then let's just continue with that :D > > br, > Jani > >> -Original Message- >> From: Edward Welbourne >> Sent: maanantai 5. joulukuuta 2022 17.17 >> To: development@qt-project.org; Jani Heikkinen ; >> I
Re: [Development] Proposal: let's change the release schedules a bit
For me, the argument that Eddy makes is very strong: a milestone or deadline right after holidays has the potential of ruining those holidays, without giving any meaningful extra time to get features done. Releases of operating systems have some relevance: new macOS and Windows versions have in recent cycles happened around March/April and October/November. But even if we try to have the Qt release shortly after those to claim quick support, in reality it would probably be “technology preview” status anyway, knowing how much time it takes to make new CI configurations significant. And TP status can just as well be achieved based on beta and preview versions. Linux distro cycles are more relevant to align with as we are upstream, but in practice I’d expect more practical value in having the first or second patch release in a distro. So in summary, I don’t think any of those need to have a strong influence on our .0 release timing. What I don’t quite understand is why a long beta period is a problem. We get valuable feedback from community and customers during that, and I vaguely remember some reports of regressions coming in pretty late in the process, just before or even after the release candidate. I don’t know whether those reports came in late because users wait until things look almost ready (i.e. RC available), or because it simply takes time before enough users try out a beta. In the former case, a longer stabilization cycle makes no difference; in the latter case, we should rather make it longer. Perhaps we have some data on that (how do download figures develop compared to tickets in JIRA reported against preview versions), but I haven’t seen anything that I’d consider conclusive. And without knowing, I don’t see much value in trying to optimize things either way. Eddy’s concern on the other hand is very tangible. Volker > On 7 Dec 2022, at 12:48, Jani Heikkinen via Development > wrote: > > Hi! > >> Jani: what is the problem with that calendar interval's present length ? > We need ~13 weeks (real working time) from the feature freeze to the final > release. Currently we have holidays during that period and so on we need to > reserve much longer calendar time for that. E.g. with Qt 6.5 this time is > planned to be a bit more than 15 weeks and with Qt 6.4 it was a bit more than > 16 weeks. > For me this hasn't been a problem at all but I have heard some other opinions > as well; someone wants to finalize new things during holidays and someone > isn't that much in holiday e.g Christmas time. For those this would give few > weeks extra implementation time between the releases... > >>> I would sooner move the schedule half a month earlier - November FF for >>> February release, May FF for August release - and accept the calendar >>> interval between the two. > Unfortunately this isn't good option; finalizing the "summer" release would > be done during summer holiday season and it won't work. For winter release > this could work... > > And please note: I am not proposing to move Qt 6.5 FF; It will stay 9.12.2022 > as planned. But this would be something for Qt 6.6 ->. But like I wrote above > this isn't anyway mandatory for me, just a proposal. If most of us prefer the > existing frame then let's just continue with that :D > > br, > Jani > >> -Original Message- >> From: Edward Welbourne >> Sent: maanantai 5. joulukuuta 2022 17.17 >> To: development@qt-project.org; Jani Heikkinen ; >> Ivan Solovev >> Subject: Re: Proposal: let's change the release schedules a bit >> >> Ivan Solovev (5 December 2022 14:42) wrote: >>> Also, as a developer, I personally find it good that we have FF before >>> the holidays. Because having it right after the holidays would anyway >>> mean that I need to have everything ready before the holidays. But >>> I'll just have less time for that. I can imagine that the Release >>> Team has different opinion, though. >> >> I have a sneaking suspicion Jani's idea is that, with no holiday between an >> August FF and October release, it may be possible to narrow the interval >> between them. However, for January to April there is a holiday intruding, >> Easter, which isn't even at a fixed point in the calendar from one year to >> the >> next. >> >> Like Ivan I do not relish the prospect of a FF shortly after a holiday; it >> would >> mean getting back from a holiday to a frantic rush to get things finished up, >> the anticipation of which might hang over the holiday. I would sooner move >> the schedule half a month earlier - November FF for February release, May >> FF for August release - and accept the calendar interval between the two. >> >> Jani: what is the problem with that calendar interval's present length ? >> >> Eddy. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: let's change the release schedules a bit
Hi! > Jani: what is the problem with that calendar interval's present length ? We need ~13 weeks (real working time) from the feature freeze to the final release. Currently we have holidays during that period and so on we need to reserve much longer calendar time for that. E.g. with Qt 6.5 this time is planned to be a bit more than 15 weeks and with Qt 6.4 it was a bit more than 16 weeks. For me this hasn't been a problem at all but I have heard some other opinions as well; someone wants to finalize new things during holidays and someone isn't that much in holiday e.g Christmas time. For those this would give few weeks extra implementation time between the releases... >> I would sooner move the schedule half a month earlier - November FF for >> February release, May FF for August release - and accept the calendar >> interval between the two. Unfortunately this isn't good option; finalizing the "summer" release would be done during summer holiday season and it won't work. For winter release this could work... And please note: I am not proposing to move Qt 6.5 FF; It will stay 9.12.2022 as planned. But this would be something for Qt 6.6 ->. But like I wrote above this isn't anyway mandatory for me, just a proposal. If most of us prefer the existing frame then let's just continue with that :D br, Jani > -Original Message- > From: Edward Welbourne > Sent: maanantai 5. joulukuuta 2022 17.17 > To: development@qt-project.org; Jani Heikkinen ; > Ivan Solovev > Subject: Re: Proposal: let's change the release schedules a bit > > Ivan Solovev (5 December 2022 14:42) wrote: > > Also, as a developer, I personally find it good that we have FF before > > the holidays. Because having it right after the holidays would anyway > > mean that I need to have everything ready before the holidays. But > > I'll just have less time for that. I can imagine that the Release > > Team has different opinion, though. > > I have a sneaking suspicion Jani's idea is that, with no holiday between an > August FF and October release, it may be possible to narrow the interval > between them. However, for January to April there is a holiday intruding, > Easter, which isn't even at a fixed point in the calendar from one year to the > next. > > Like Ivan I do not relish the prospect of a FF shortly after a holiday; it > would > mean getting back from a holiday to a frantic rush to get things finished up, > the anticipation of which might hang over the holiday. I would sooner move > the schedule half a month earlier - November FF for February release, May > FF for August release - and accept the calendar interval between the two. > > Jani: what is the problem with that calendar interval's present length ? > > Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: let's change the release schedules a bit
I think one of the considerations of releasing March and Septemper was to have a chance to be considered for Ubuntu's April and October releases. I'm not sure if I remember correctly, though, and also not if that had the desired effect (if it was a reason in the first place). ++ Eike > Am 05/12/2022 um 12:40 schrieb Jani Heikkinen via Development > : > > Hi, > > I am proposing a change to the our release "frame": > > Currently we are releasing new Qt minor releases in March and in September. > This is working quite well, but it is forcing us to have a Feature Freeze > always before holidays and that's lengthening the calendar time needed > between the feature freeze and the final release. > > But if we would release minor releases in April and October, that would allow > us to move FF also after the holidays: So FF for April release would be in > January and FF for October release would be in August. > > Any opinions or objections? > > br, > Jani > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: let's change the release schedules a bit
Ivan Solovev (5 December 2022 14:42) wrote: > Also, as a developer, I personally find it good that we have FF before > the holidays. Because having it right after the holidays would anyway > mean that I need to have everything ready before the holidays. But > I'll just have less time for that. I can imagine that the Release > Team has different opinion, though. I have a sneaking suspicion Jani's idea is that, with no holiday between an August FF and October release, it may be possible to narrow the interval between them. However, for January to April there is a holiday intruding, Easter, which isn't even at a fixed point in the calendar from one year to the next. Like Ivan I do not relish the prospect of a FF shortly after a holiday; it would mean getting back from a holiday to a frantic rush to get things finished up, the anticipation of which might hang over the holiday. I would sooner move the schedule half a month earlier - November FF for February release, May FF for August release - and accept the calendar interval between the two. Jani: what is the problem with that calendar interval's present length ? Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: let's change the release schedules a bit
Hi Jani, I'm not sure that I understand your proposal. Currently we have FF on the 9th of December, and the release in March. So, it's roughly 3 months between FF and release. Now you propose to shift FF to January (I assume, also around 10th ), and the release to April. That gives the same 3 months between FF and release. Am I missing anything? Also, as a developer, I personally find it good that we have FF before the holidays. Because having it right after the holidays would anyway mean that I need to have everything ready before the holidays. But I'll just have less time for that. I can imagine that the Release Team has different opinion, though. Best regards, Ivan From: Development on behalf of Jani Heikkinen via Development Sent: Monday, December 5, 2022 12:40 PM To: development@qt-project.org Subject: [Development] Proposal: let's change the release schedules a bit Hi, I am proposing a change to the our release "frame": Currently we are releasing new Qt minor releases in March and in September. This is working quite well, but it is forcing us to have a Feature Freeze always before holidays and that's lengthening the calendar time needed between the feature freeze and the final release. But if we would release minor releases in April and October, that would allow us to move FF also after the holidays: So FF for April release would be in January and FF for October release would be in August. Any opinions or objections? br, Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Proposal: let's change the release schedules a bit
Hi, I am proposing a change to the our release "frame": Currently we are releasing new Qt minor releases in March and in September. This is working quite well, but it is forcing us to have a Feature Freeze always before holidays and that's lengthening the calendar time needed between the feature freeze and the final release. But if we would release minor releases in April and October, that would allow us to move FF also after the holidays: So FF for April release would be in January and FF for October release would be in August. Any opinions or objections? br, Jani ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
