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

[Tuukka Turunen]

Great! Hopefully the remaining steps towards alpha go nicely. 

There are quite a few items not yet listed at: 
https://wiki.qt.io/New_Features_in_Qt_5.15 

The new feature highlight is valuable for users, so please lift a few of the 
key items for each module into the list. Think what are the most important 
items to tell our users.

We should have more content in place before the alpha, and finalize this before 
the first beta release. 

Yours,

Tuukka

On 11.2.2020, 11.12, "Development on behalf of Volker Hilsheimer" 
 wrote:

> On 10 Feb 2020, at 13:44, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> It seems that there is still some work needed to finalize deprecations 
and replacement for Qt 5.15
> 
> We had some discussion here in Qt Company and based on that I propose:
> 
> - Let's put Alpha out after this header view feature is in.


HeaderView change merged this morning:

https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170

so we should be good to go with the Alpha.

Cheers,
Volker



> - Let's agree these deprecations can be done still even the FF is in 
effect. But let's try to finalize deprecations and replacements as soon as 
possible.  Blocking Alpha until all these are in doesn't make sense at this 
point anymore.
> - Before Beta1 these deprecations needs approval of module maintainer
> - And after Beta1 adding new deprecations needs Lars's approval
> 
> That should bring us enough flexibility in this special situation without 
compromising or risking the Qt 5.15 release schedule too much.
> 
> br,
> jani
> 
> 
> 
> 
>> -Original Message-
>> From: Development  On Behalf Of
>> Jani Heikkinen
>> Sent: torstai 6. helmikuuta 2020 10.03
>> To: Mitch Curtis ; Lars Knoll ; 
Yulong
    >> Bai 
>> Cc: Qt development mailing list ;
>> releasing@qt-project.org
>> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze 
is
>> in effect now
>> 
>>> -Original Message-
>>> From: Mitch Curtis 
>>> Sent: keskiviikko 5. helmikuuta 2020 15.40
>>> To: Jani Heikkinen ; Lars Knoll
    >>> ; Yulong Bai 
>>> Cc: Volker Hilsheimer ; Qt development
>>> mailing list ; releasing@qt-project.org
>>> Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature
>>> Freeze is in effect now
>>> 
>>> 
>>> Hi Jani.
>>> 
>>> - It's a vital part of creating a table in Qt Quick, and something
>>> that is non- trivial for a good chunk of users to implement themselves.
>>> - I think you and Lars have already said it's low risk, which is true.
>>> - I don't think this counts as justification, but.. it's been in the
>>> works for a while, and we really shouldn't delay it any longer.
>>> - I'm also confident we will be ready to merge it today.
>> 
>> Hi,
>> 
>> Ok, nice to hear it won't take that long to get this in. And based on all
>> discussion related to this & qt5.15 overall let's take this in Qt 5.15.
>> 
>> We have other issues delaying alpha packages as well so this won't be 
only
>> thing delaying it  Let's try to finalize alpha content during this week 
& get
>> Alpha out during next one
>> 
>> Br,
>> Jani
>> 
>> 
>> ___
>> Development mailing list
>> developm...@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> developm...@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
developm...@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Volker Hilsheimer]

> On 10 Feb 2020, at 13:44, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> It seems that there is still some work needed to finalize deprecations and 
> replacement for Qt 5.15
> 
> We had some discussion here in Qt Company and based on that I propose:
> 
> - Let's put Alpha out after this header view feature is in.


HeaderView change merged this morning:

https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170

so we should be good to go with the Alpha.

Cheers,
Volker



> - Let's agree these deprecations can be done still even the FF is in effect. 
> But let's try to finalize deprecations and replacements as soon as possible.  
> Blocking Alpha until all these are in doesn't make sense at this point 
> anymore.
> - Before Beta1 these deprecations needs approval of module maintainer
> - And after Beta1 adding new deprecations needs Lars's approval
> 
> That should bring us enough flexibility in this special situation without 
> compromising or risking the Qt 5.15 release schedule too much.
> 
> br,
> jani
> 
> 
> 
> 
>> -Original Message-
>> From: Development  On Behalf Of
>> Jani Heikkinen
>> Sent: torstai 6. helmikuuta 2020 10.03
>> To: Mitch Curtis ; Lars Knoll ; Yulong
>> Bai 
>> Cc: Qt development mailing list ;
>> releasing@qt-project.org
>> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
>> in effect now
>> 
>>> -Original Message-
>>> From: Mitch Curtis 
>>> Sent: keskiviikko 5. helmikuuta 2020 15.40
>>> To: Jani Heikkinen ; Lars Knoll
>>> ; Yulong Bai 
>>> Cc: Volker Hilsheimer ; Qt development
>>> mailing list ; releasing@qt-project.org
>>> Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature
>>> Freeze is in effect now
>>> 
>>> 
>>> Hi Jani.
>>> 
>>> - It's a vital part of creating a table in Qt Quick, and something
>>> that is non- trivial for a good chunk of users to implement themselves.
>>> - I think you and Lars have already said it's low risk, which is true.
>>> - I don't think this counts as justification, but.. it's been in the
>>> works for a while, and we really shouldn't delay it any longer.
>>> - I'm also confident we will be ready to merge it today.
>> 
>> Hi,
>> 
>> Ok, nice to hear it won't take that long to get this in. And based on all
>> discussion related to this & qt5.15 overall let's take this in Qt 5.15.
>> 
>> We have other issues delaying alpha packages as well so this won't be only
>> thing delaying it  Let's try to finalize alpha content during this week & 
>> get
>> Alpha out during next one
>> 
>> Br,
>> Jani
>> 
>> 
>> ___
>> Development mailing list
>> developm...@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> developm...@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Jani Heikkinen]

Hi all,

It seems that there is still some work needed to finalize deprecations and 
replacement for Qt 5.15

We had some discussion here in Qt Company and based on that I propose:

- Let's put Alpha out after this header view feature is in.
- Let's agree these deprecations can be done still even the FF is in effect. 
But let's try to finalize deprecations and replacements as soon as possible.  
Blocking Alpha until all these are in doesn't make sense at this point anymore.
- Before Beta1 these deprecations needs approval of module maintainer
- And after Beta1 adding new deprecations needs Lars's approval

That should bring us enough flexibility in this special situation without 
compromising or risking the Qt 5.15 release schedule too much.

br,
jani




> -Original Message-
> From: Development  On Behalf Of
> Jani Heikkinen
> Sent: torstai 6. helmikuuta 2020 10.03
> To: Mitch Curtis ; Lars Knoll ; Yulong
> Bai 
> Cc: Qt development mailing list ;
> releasing@qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
> 
> > -Original Message-
> > From: Mitch Curtis 
> > Sent: keskiviikko 5. helmikuuta 2020 15.40
> > To: Jani Heikkinen ; Lars Knoll
> > ; Yulong Bai 
> > Cc: Volker Hilsheimer ; Qt development
> > mailing list ; releasing@qt-project.org
> > Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature
> > Freeze is in effect now
> >
> >
> > Hi Jani.
> >
> > - It's a vital part of creating a table in Qt Quick, and something
> > that is non- trivial for a good chunk of users to implement themselves.
> > - I think you and Lars have already said it's low risk, which is true.
> > - I don't think this counts as justification, but.. it's been in the
> > works for a while, and we really shouldn't delay it any longer.
> > - I'm also confident we will be ready to merge it today.
> 
> Hi,
> 
> Ok, nice to hear it won't take that long to get this in. And based on all
> discussion related to this & qt5.15 overall let's take this in Qt 5.15.
> 
> We have other issues delaying alpha packages as well so this won't be only
> thing delaying it  Let's try to finalize alpha content during this week & get
> Alpha out during next one
> 
> Br,
> Jani
> 
> 
> ___
> Development mailing list
> developm...@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Tuukka Turunen]

Hi,

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. 

Yours,

Tuukka
 

On 7.2.2020, 9.59, "Releasing on behalf of Eskil Abrahamsen Blomfeldt" 
 wrote:


On 05.02.2020 13:04, Jani Heikkinen wrote:
>
>> -Original Message-
>> From: Eskil Abrahamsen Blomfeldt 
>> Sent: keskiviikko 5. helmikuuta 2020 13.06
>> To: Edward Welbourne ; Jani Heikkinen
>> ; Lars Knoll ; Volker Hilsheimer
>> 
>> Cc: Qt development mailing list ;
>> releasing@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 f

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

[Edward Welbourne]

On 05.02.2020 11:50, Edward Welbourne asked:
 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 ?

Eskil Abrahamsen Blomfeldt (keskiviikko 5. helmikuuta 2020 13.06) replied:
>>> 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.

Makes sense.  See below.

On 05.02.2020 13:04, Jani Heikkinen wrote:
>> 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...

Eskil Abrahamsen Blomfeldt (7 February 2020 08:58)
> You are looking at this from a very different perspective than me,
> which is totally understandable.

Indeed - still, let us all try to see this from each others'
perspectives.  That gives a better chance of finding a resolution we can
all be happy with.

> 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.

On the other hand, if a change that should be subject to FF turns out to
have problems that mean it wasn't actually ready in time, how severe can
those problems be and *not* imply that we should keep that feature out ?

This week, we've given special dispensation for things that were delayed
due to minor problems that were known at the time of FF.  That seems a
reasonable level of flexibility in an otherwise hard FF.  If a change
that seemed ready for merge last Friday turns out to cause problems that
weren't anticipated then, unless they are promptly resolved and low-risk
(given the previously accepted change), it makes sense to block that
change until the next release - otherwise, the release process becomes
chaos, as it voids FF's rule about what's in and what's out.

[snip]

> 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.

I don't think anyone is currently standing for that position: if the
only thing that's kept a change out is CI failure, or being staged
alongside someone else's broken change [0] on the day of FF, then I
think we're all in agreement that the change "made it in time".  On the
other hand, the broken change whose premature staging blocked others'
changes from getting integrated *should* be subject to scrutiny - if it
can be fixed safely, satisfactorily and promptly then fine, but if it's
going to delay other changes with further integration failures then we
should be ready to Just Say No to it after the FF deadline passes.

[0] and you know which change I'm thinking of, Eskil.
I'm happy to see it got fixed up quickly ;^>

We presently have (only semi-formally) a process that requires API
changes to be in by the FF deadline but provides for community
(i.e. this list) approval of stragglers, when we are confident they are
unlikely to harm stability or schedule.  That seems workable.

Eddy.
___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Eskil Abrahamsen Blomfeldt]

On 05.02.2020 13:04, Jani Heikkinen wrote:
>
>> -Original Message-
>> From: Eskil Abrahamsen Blomfeldt 
>> Sent: keskiviikko 5. helmikuuta 2020 13.06
>> To: Edward Welbourne ; Jani Heikkinen
>> ; Lars Knoll ; Volker Hilsheimer
>> 
>> Cc: Qt development mailing list ;
>> releasing@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 

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

[Volker Hilsheimer]

This merged just now 邏 Will update wiki tomorrow.

Apologies for not getting this finished earlier, and thanks for the flexibility 


Cheers,
Volker



From: Jani Heikkinen 
Sent: Wednesday, February 5, 2020 12:29:27 PM
To: Volker Hilsheimer ; Edward Welbourne 

Cc: Lars Knoll ; developm...@qt-project.org 
; releasing@qt-project.org 

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

> -Original Message-
> From: Volker Hilsheimer 
> Sent: keskiviikko 5. helmikuuta 2020 13.10
> To: Edward Welbourne 
> Cc: Jani Heikkinen ; Lars Knoll ;
> developm...@qt-project.org; releasing@qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
>
> > On 5 Feb 2020, at 11:50, Edward Welbourne 
> wrote:
> >
> > On 4 Feb 2020, at 16:56, Volker Hilsheimer 
> wrote:
> >>>> I’ve been struggling a bit more than expected with getting the
> >>>> implementation of "move a file or directory to the trash" pass CI.
> >>>> It’s a popular feature request:
> >>>>
> >>>> https://bugreports.qt.io/browse/QTBUG-47703
> >>>>
> >>>> The basic implementation and private APIs have been in for a bit,
> >>>> but required a bit of follow-up, which delayed the merging of the
> >>>> commit that adds the public API in:
> >>>>
> >>>> https://codereview.qt-project.org/c/qt/qtbase/+/287373
> >
> > Lars Knoll (Tuesday, February 4, 2020 8:41 PM)
> >>> +1 from my side. It doesn’t have dependencies on any other code, so
> >>> it can’t break anything else neither.
> >
> > 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
> ?
> >
> > In the present instance (modulo: I may have misunderstood some of
> > what's going on), we have a change that's integrated in 5.15 but won't
> > merge up to dev because dev has a platform 5.15 lacks, on which the
> > change doesn't compile.  This is blocking 5.15 -> dev merges in qtbase
> > at present.  Volker is trying to fix that in 5.15, so that the
> > merge-up can go ahead.  Either we revert the commit that introduced
> > move-to-trash, to unblock merging, or we need to fix in 5.15 the build
> > that's only done in dev.  A revert means backing out of the feature,
> > even though (IIUC) it works just fine in 5.15.
>
>
> The change was indeed approved before FF, and the implementation is in
> thanks to that; the public API with the unit test is not because it turned 
> out to
> be a surprisingly annoying feature to test in such a way that it passes our 
> CI :(
>
> The world certainly doesn’t end if we don’t get this in, but OTOH it’s silly 
> to
> have to wait with this until Qt 6. But this particular feature shouldn’t 
> block the
> Alpha either; the testing of the release machinery, and the feedback we get
> through Alpha to the new modules and the more significant additions in Qt
> 5.15 isn’t invalidated by this being added after Alpha.
>
> But your call, Jani. If we don’t get it in, then I will revert the already 
> merged
> changes since those internal implementations don’t have a public API.

Ok, fair enough. Let's take this in Qt 5.15; it seems this shouldn't cause too 
much harm or delays.

And let's not delay Alpha because of this even I do think we should have all 
new features & APIs in Alpha already. But I know public API will be changed 
after Alpha because of API review findings so it doesn't matter that much if 
simple API methods are added after the Alpha release as well 

br,
Jani
___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Shawn Rutledge]

> On 5 Feb 2020, at 16:31, Edward Welbourne  wrote:
> 
> Shawn Rutledge (5 February 2020 14:14)
>> So I’m strongly in favor of continuing to do deprecations as long as
>> possible.  A deprecation is not something that can break existing
>> functionality, so it’s no real risk as long as we’re sure we really
>> want to deprecate it.
> 
> A deprecation can break existing builds, for those who enable
> warnings-are-errors.  

It defeats the purpose of deprecation to do that before you are ready.  It’s 
something to be done later, to verify that you really have gotten rid of all 
uses of the old API.  “Later” should not be as long a time as it has been in 
the past (as in deprecating something only in documentation in 5.0, and then 
waiting until 5.14 to deal with the consequences); but it also IMO should not 
be treated as a P0 blocker issue hanging over our heads the instant after 
deprecating something, to go and rewrite all uses in all modules.  It’s 
technical debt though.

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Edward Welbourne]

Shawn Rutledge (5 February 2020 14:14)
> So I’m strongly in favor of continuing to do deprecations as long as
> possible.  A deprecation is not something that can break existing
> functionality, so it’s no real risk as long as we’re sure we really
> want to deprecate it.

A deprecation can break existing builds, for those who enable
warnings-are-errors.  Consequently, in the API change review, reviewers
need to be able to see all deprecations, in order to be able to raise
objections to any that are going to cause pain.

I am well aware of how being kept from Qt 6 work makes it hard to
discover the deprecations that'll be needed in 5.15 to support that Qt 6
work, once we get to it - I spent much of the last fortnight frantically
getting those deprecations (and some API consolidations I noticed in the
process) sorted out, precisely because I understood feature freeze as a
hard cut-off.  Dealing with it as such gives everyone a clearer view of
what we're doing.

I accept that the final Qt 5 release is special - and agree that the
usual "we do time-based, so your change that missed FF only has to wait
half a year" isn't as true as it would be at other times - but we do
need to have visibility for changes to the API - including deprecations
- so that our API change reviews can do their job properly.  That
includes clients of an API getting a chance to object to a deprecation.

So please be sure to comment on API change reviews if you even suspect
you may be about to decide to deprecate things that haven't yet been
sorted out before feature freeze.  API change reviewers need to know
about them.


We seem to have some diversity of opinion on how hard a cut-off the
feature freeze is meant to be: that's a topic we need to discuss and
answer, if we're to have release processes we can trust.  On the one
hand, the need for predictability in our release process means we need
to have deadlines and stick to them.  On the other hand, various
practicalities make it necessary to have some flexibility.  I think we
need to revisit the incomplete QUIP 11 and actually document which
things cut off when.

https://codereview.qt-project.org/c/meta/quips/+/228450

Eddy.
___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Mitch Curtis]

> -Original Message-
> From: Releasing  On Behalf Of Jani
> Heikkinen
> Sent: Wednesday, 5 February 2020 6:37 AM
> To: Lars Knoll ; Yulong Bai 
> Cc: Volker Hilsheimer ; Qt development mailing list
> ; releasing@qt-project.org
> Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
> 
> Hi!
> 
> Yeah, for me this seems to be quite low risky addition as well. Only concern 
> is
> that we need to delay the Alpha release because of this late addition. We
> have Alpha content in place already now and at least in theory we should
> delay it until all new features are in... So adding 2 weeks delay to there
> doesn't sound that nice to me at this point.; delays are usually causing
> problems & unnecessary hassle later phases of releasing :( And taking this in
> between Alpha and beta doesn't sound that well to me either; what is the
> purpose of Alpha if there isn't all known features in...
> 
> Why this is so important that we should get the exception & go in after FF?

Hi Jani.

- It's a vital part of creating a table in Qt Quick, and something that is 
non-trivial for a good chunk of users to implement themselves.
- I think you and Lars have already said it's low risk, which is true.
- I don't think this counts as justification, but.. it's been in the works for 
a while, and we really shouldn't delay it any longer.
- I'm also confident we will be ready to merge it today.

Cheers.
 
> br,
> Jani
> 
> 
> From: Lars Knoll 
> Sent: Tuesday, February 4, 2020 3:50 PM
> To: Yulong Bai
> Cc: Jani Heikkinen; Qt development mailing list; releasing@qt-project.org;
> Volker Hilsheimer
> Subject: Re: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect
> now
> 
> I’d be ok with extending the deadline for this one item until end of next
> week. It shouldn’t be able to break other things as far as I can tell.
> 
> But would like to hear Jani’s opinion as well. If he’s also ok go ahead, but 
> it
> really needs to get approved and merged quickly.
> 
> Cheers,
> Lars
> 
> On 4 Feb 2020, at 14:39, Yulong Bai
> mailto:yulong@qt.io>> wrote:
> 
> Hello,
> 
> HeaderView is almost done but I just missed the feature-freeze. I will have it
> ready by this Friday.
> 
> So, is it OK for everybody that I merge it after the 5.15 feature freeze. It's
> here https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170
> 
> br,
> Yulong
> Software Engineer
> 
> From: Jani Heikkinen mailto:jani.heikki...@qt.io>>
> Sent: 03 February 2020 06:35
> To: developm...@qt-project.org<mailto:developm...@qt-project.org>
> mailto:developm...@qt-project.org>>;
> releasing@qt-project.org<mailto:releasing@qt-project.org>  project.org<mailto:releasing@qt-project.org>>
> Subject: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> 
> Hi all,
> 
> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15'
> anymore. Please update Qt 5.15 new features page
> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite
> empty still...
> 
> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can 
> get it
> out already during this week.
> 
> API review for Qt 5.15 will start soon as well. Please do reviews immediately
> when available.
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> ___
> Releasing mailing list
> Releasing@qt-project.org
> https://lists.qt-project.org/listinfo/releasing
___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Shawn Rutledge]

On 5 Feb 2020, at 13:04, Jani Heikkinen 
mailto:jani.heikki...@qt.io>> wrote:

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…

It’s the end of the Qt 5 series, so time to the next Qt 5 release after this 
one is infinite (it won't happen at all).  Users won’t switch to Qt 6 anytime 
soon.  Missing functionality will hurt them more than usual.  I’m not talking 
about pie-in-the-sky ideas, but features that are close to done and were 
promised for a long time already; and even more so, missing features that are 
blocking imminent releases of other modules that were promised, or already paid 
for.

Failing to get all the deprecations in place for things we want to remove in Qt 
6 will also hurt users a lot.  So I think we need to be more flexible than 
usual about getting those in.  And those of us who had real work to add 
features in 5.15 have not yet had time to work on the sort of Qt 6 things that 
could result in the need to add deprecations in 5.15.  (And that will probably 
go on for a few more weeks, too.)

If you argue against getting more deprecations in place in 5.15, then you are 
also implicitly arguing in favor of having more SC breaks in Qt 6.

So I’m strongly in favor of continuing to do deprecations as long as possible.  
A deprecation is not something that can break existing functionality, so it’s 
no real risk as long as we’re sure we really want to deprecate it.

The exact timing of the 5.15 release could even slip more than usual; what will 
it really matter?  For once I think we should be concerned more about quality 
than timing.  As long as we get 5.15.0 out within the first half of the year, 
we will satisfy our duty to the almighty #%#$% schedule.

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Jani Heikkinen]

> -Original Message-
> From: Eskil Abrahamsen Blomfeldt 
> Sent: keskiviikko 5. helmikuuta 2020 13.06
> To: Edward Welbourne ; Jani Heikkinen
> ; Lars Knoll ; Volker Hilsheimer
> 
> Cc: Qt development mailing list ;
> releasing@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...

> The slack to accommodate these intrinsic delays need to be in the release
> plan in my opinion, and not in each developer's individual plan for merging
> their changes.

I have to disagree. Everyone knows that there is flakiness/problems in 
integrations and so on changes has to be ready early enough so that there is 
still time to pass the CI. That's why FF date is agreed & informed quite early 
& there is several heads-up telling it is coming closer...

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. 

br,
Jani
___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Jani Heikkinen]

> -Original Message-
> From: Volker Hilsheimer 
> Sent: keskiviikko 5. helmikuuta 2020 13.10
> To: Edward Welbourne 
> Cc: Jani Heikkinen ; Lars Knoll ;
> developm...@qt-project.org; releasing@qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
> 
> > On 5 Feb 2020, at 11:50, Edward Welbourne 
> wrote:
> >
> > On 4 Feb 2020, at 16:56, Volker Hilsheimer 
> wrote:
> >>>> I’ve been struggling a bit more than expected with getting the
> >>>> implementation of "move a file or directory to the trash" pass CI.
> >>>> It’s a popular feature request:
> >>>>
> >>>> https://bugreports.qt.io/browse/QTBUG-47703
> >>>>
> >>>> The basic implementation and private APIs have been in for a bit,
> >>>> but required a bit of follow-up, which delayed the merging of the
> >>>> commit that adds the public API in:
> >>>>
> >>>> https://codereview.qt-project.org/c/qt/qtbase/+/287373
> >
> > Lars Knoll (Tuesday, February 4, 2020 8:41 PM)
> >>> +1 from my side. It doesn’t have dependencies on any other code, so
> >>> it can’t break anything else neither.
> >
> > 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
> ?
> >
> > In the present instance (modulo: I may have misunderstood some of
> > what's going on), we have a change that's integrated in 5.15 but won't
> > merge up to dev because dev has a platform 5.15 lacks, on which the
> > change doesn't compile.  This is blocking 5.15 -> dev merges in qtbase
> > at present.  Volker is trying to fix that in 5.15, so that the
> > merge-up can go ahead.  Either we revert the commit that introduced
> > move-to-trash, to unblock merging, or we need to fix in 5.15 the build
> > that's only done in dev.  A revert means backing out of the feature,
> > even though (IIUC) it works just fine in 5.15.
> 
> 
> The change was indeed approved before FF, and the implementation is in
> thanks to that; the public API with the unit test is not because it turned 
> out to
> be a surprisingly annoying feature to test in such a way that it passes our 
> CI :(
> 
> The world certainly doesn’t end if we don’t get this in, but OTOH it’s silly 
> to
> have to wait with this until Qt 6. But this particular feature shouldn’t 
> block the
> Alpha either; the testing of the release machinery, and the feedback we get
> through Alpha to the new modules and the more significant additions in Qt
> 5.15 isn’t invalidated by this being added after Alpha.
> 
> But your call, Jani. If we don’t get it in, then I will revert the already 
> merged
> changes since those internal implementations don’t have a public API.

Ok, fair enough. Let's take this in Qt 5.15; it seems this shouldn't cause too 
much harm or delays. 

And let's not delay Alpha because of this even I do think we should have all 
new features & APIs in Alpha already. But I know public API will be changed 
after Alpha because of API review findings so it doesn't matter that much if 
simple API methods are added after the Alpha release as well 

br,
Jani
___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Volker Hilsheimer]

> On 5 Feb 2020, at 11:50, Edward Welbourne  wrote:
> 
> On 4 Feb 2020, at 16:56, Volker Hilsheimer  wrote:
 I’ve been struggling a bit more than expected with getting the
 implementation of "move a file or directory to the trash" pass
 CI. It’s a popular feature request:
 
 https://bugreports.qt.io/browse/QTBUG-47703
 
 The basic implementation and private APIs have been in for a bit,
 but required a bit of follow-up, which delayed the merging of the
 commit that adds the public API in:
 
 https://codereview.qt-project.org/c/qt/qtbase/+/287373
> 
> Lars Knoll (Tuesday, February 4, 2020 8:41 PM)
>>> +1 from my side. It doesn’t have dependencies on any other code, so
>>> it can’t break anything else neither.
> 
> 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 ?
> 
> In the present instance (modulo: I may have misunderstood some of what's
> going on), we have a change that's integrated in 5.15 but won't merge up
> to dev because dev has a platform 5.15 lacks, on which the change
> doesn't compile.  This is blocking 5.15 -> dev merges in qtbase at
> present.  Volker is trying to fix that in 5.15, so that the merge-up can
> go ahead.  Either we revert the commit that introduced move-to-trash, to
> unblock merging, or we need to fix in 5.15 the build that's only done in
> dev.  A revert means backing out of the feature, even though (IIUC) it
> works just fine in 5.15.


The change was indeed approved before FF, and the implementation is in thanks 
to that; the public API with the unit test is not because it turned out to be a 
surprisingly annoying feature to test in such a way that it passes our CI :(

The world certainly doesn’t end if we don’t get this in, but OTOH it’s silly to 
have to wait with this until Qt 6. But this particular feature shouldn’t block 
the Alpha either; the testing of the release machinery, and the feedback we get 
through Alpha to the new modules and the more significant additions in Qt 5.15 
isn’t invalidated by this being added after Alpha.

But your call, Jani. If we don’t get it in, then I will revert the already 
merged changes since those internal implementations don’t have a public API.

That the change that passed CI for 5.15 blocks the merge to dev is not related 
to FF, but because we are testing different platforms in CI for dev than we do 
for 5.15. The follow-up that fixes the build for that merge is already in 5.15, 
and the merge needs to be updated to include those changes. Liang knows about 
that.


Cheers,
Volker

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Eskil Abrahamsen Blomfeldt]

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. 
The slack to accommodate these intrinsic delays need to be in the 
release plan in my opinion, and not in each developer's individual plan 
for merging their changes.

If it turns out the change cannot be merged as-is and needs additional 
fixing, I think it should be addressed as any other change that doesn't 
match the conditions above: on a case-by-case basis, considering value 
vs. risk in each case.

In the particular case you mention, I think we should fix the issues 
with the feature in 5.15 rather than revert it. The reason we have 
several months between freeze and release is so that we have time for 
stabilization work such as this.

-- 
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

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Edward Welbourne]

On 4 Feb 2020, at 16:56, Volker Hilsheimer  wrote:
>>> I’ve been struggling a bit more than expected with getting the
>>> implementation of "move a file or directory to the trash" pass
>>> CI. It’s a popular feature request:
>>>
>>> https://bugreports.qt.io/browse/QTBUG-47703
>>>
>>> The basic implementation and private APIs have been in for a bit,
>>> but required a bit of follow-up, which delayed the merging of the
>>> commit that adds the public API in:
>>>
>>> https://codereview.qt-project.org/c/qt/qtbase/+/287373

Lars Knoll (Tuesday, February 4, 2020 8:41 PM)
>> +1 from my side. It doesn’t have dependencies on any other code, so
>> it can’t break anything else neither.

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 ?

In the present instance (modulo: I may have misunderstood some of what's
going on), we have a change that's integrated in 5.15 but won't merge up
to dev because dev has a platform 5.15 lacks, on which the change
doesn't compile.  This is blocking 5.15 -> dev merges in qtbase at
present.  Volker is trying to fix that in 5.15, so that the merge-up can
go ahead.  Either we revert the commit that introduced move-to-trash, to
unblock merging, or we need to fix in 5.15 the build that's only done in
dev.  A revert means backing out of the feature, even though (IIUC) it
works just fine in 5.15.

Eddy.
___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Jani Heikkinen]

Hi!

Yeah, for me this seems to be quite low risky addition as well. Only concern is 
that we need to delay the Alpha release because of this late addition. We have 
Alpha content in place already now and at least in theory we should delay it 
until all new features are in... So adding 2 weeks delay to there doesn't sound 
that nice to me at this point.; delays are usually causing problems & 
unnecessary hassle later phases of releasing :( And taking this in between 
Alpha and beta doesn't sound that well to me either; what is the purpose of 
Alpha if there isn't all known features in...

Why this is so important that we should get the exception & go in after FF?

br,
Jani


From: Lars Knoll 
Sent: Tuesday, February 4, 2020 3:50 PM
To: Yulong Bai
Cc: Jani Heikkinen; Qt development mailing list; releasing@qt-project.org; 
Volker Hilsheimer
Subject: Re: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

I’d be ok with extending the deadline for this one item until end of next week. 
It shouldn’t be able to break other things as far as I can tell.

But would like to hear Jani’s opinion as well. If he’s also ok go ahead, but it 
really needs to get approved and merged quickly.

Cheers,
Lars

On 4 Feb 2020, at 14:39, Yulong Bai mailto:yulong@qt.io>> 
wrote:

Hello,

HeaderView is almost done but I just missed the feature-freeze. I will have it 
ready by this Friday.

So, is it OK for everybody that I merge it after the 5.15 feature freeze. It's 
here https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170

br,
Yulong
Software Engineer

From: Jani Heikkinen mailto:jani.heikki...@qt.io>>
Sent: 03 February 2020 06:35
To: developm...@qt-project.org 
mailto:developm...@qt-project.org>>; 
releasing@qt-project.org 
mailto:releasing@qt-project.org>>
Subject: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

Hi all,

Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' anymore. 
Please update Qt 5.15 new features page 
(https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite empty 
still...

Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can get 
it out already during this week.

API review for Qt 5.15 will start soon as well. Please do reviews immediately 
when available.

br,
Jani Heikkinen
Release Manager

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Lars Knoll]

> On 4 Feb 2020, at 16:56, Volker Hilsheimer  wrote:
> 
>> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
>> 
>> Hi all,
>> 
>> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
>> anymore. Please update Qt 5.15 new features page 
>> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite empty 
>> still...
>> 
>> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can 
>> get it out already during this week.
>> 
>> API review for Qt 5.15 will start soon as well. Please do reviews 
>> immediately when available.
>> 
>> br,
>> Jani Heikkinen
> 
> 
> I’ve been struggling a bit more than expected with getting the implementation 
> of "move a file or directory to the trash" pass CI. It’s a popular feature 
> request:
> 
> https://bugreports.qt.io/browse/QTBUG-47703
> 
> The basic implementation and private APIs have been in for a bit, but 
> required a bit of follow-up, which delayed the merging of the commit that 
> adds the public API in:
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/287373

+1 from my side. It doesn’t have dependencies on any other code, so it can’t 
break anything else neither.

Cheers,
Lars

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Volker Hilsheimer]

> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
> anymore. Please update Qt 5.15 new features page 
> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite empty 
> still...
> 
> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can 
> get it out already during this week.
> 
> API review for Qt 5.15 will start soon as well. Please do reviews immediately 
> when available.
> 
> br,
> Jani Heikkinen


I’ve been struggling a bit more than expected with getting the implementation 
of "move a file or directory to the trash" pass CI. It’s a popular feature 
request:

https://bugreports.qt.io/browse/QTBUG-47703

The basic implementation and private APIs have been in for a bit, but required 
a bit of follow-up, which delayed the merging of the commit that adds the 
public API in:

https://codereview.qt-project.org/c/qt/qtbase/+/287373

Ok to merge?

Cheers,
Volker

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Lars Knoll]

I’d be ok with extending the deadline for this one item until end of next week. 
It shouldn’t be able to break other things as far as I can tell.

But would like to hear Jani’s opinion as well. If he’s also ok go ahead, but it 
really needs to get approved and merged quickly.

Cheers,
Lars

On 4 Feb 2020, at 14:39, Yulong Bai mailto:yulong@qt.io>> 
wrote:

Hello,

HeaderView is almost done but I just missed the feature-freeze. I will have it 
ready by this Friday.

So, is it OK for everybody that I merge it after the 5.15 feature freeze. It's 
here https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170

br,
Yulong
Software Engineer

From: Jani Heikkinen mailto:jani.heikki...@qt.io>>
Sent: 03 February 2020 06:35
To: developm...@qt-project.org 
mailto:developm...@qt-project.org>>; 
releasing@qt-project.org 
mailto:releasing@qt-project.org>>
Subject: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

Hi all,

Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' anymore. 
Please update Qt 5.15 new features page 
(https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite empty 
still...

Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can get 
it out already during this week.

API review for Qt 5.15 will start soon as well. Please do reviews immediately 
when available.

br,
Jani Heikkinen
Release Manager

___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing

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

[Yulong Bai]

Hello,

HeaderView is almost done but I just missed the feature-freeze. I will have it 
ready by this Friday.

So, is it OK for everybody that I merge it after the 5.15 feature freeze. It's 
here https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170

br,
Yulong
Software Engineer

From: Jani Heikkinen 
Sent: 03 February 2020 06:35
To: developm...@qt-project.org ; 
releasing@qt-project.org 
Subject: [Development] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

Hi all,

Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' anymore. 
Please update Qt 5.15 new features page 
(https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite empty 
still...

Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we can get 
it out already during this week.

API review for Qt 5.15 will start soon as well. Please do reviews immediately 
when available.

br,
Jani Heikkinen
Release Manager




___
Releasing mailing list
Releasing@qt-project.org
https://lists.qt-project.org/listinfo/releasing