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
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
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
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
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
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
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
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
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
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 l
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
11 matches
Mail list logo
