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 <development-boun...@qt-project.org> on behalf of Volker 
Hilsheimer via Development <development@qt-project.org>
Date: Thursday, 8. December 2022 at 14.03
To: Jani Heikkinen <jani.heikki...@qt.io>
Cc: development@qt-project.org <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 
> <development@qt-project.org> 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 <edward.welbou...@qt.io>
>> Sent: maanantai 5. joulukuuta 2022 17.17
>> To: development@qt-project.org; Jani Heikkinen <jani.heikki...@qt.io>;
>> Ivan Solovev <ivan.solo...@qt.io>
>> 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

_______________________________________________
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

Reply via email to