[Development] Starting preparations for Qt 5.1

[Ahumada Sergio]

Hi,

Making of Qt 5.1 minor release will soon start:

- Plan is to move 'dev' into 'stable' branch on March 19th.

- After March 19th any changes that are required to get in for 5.1
need to be pushed into 'stable' branch. So if your needed changes don't make it today,
please wait after the merge is done and re-target it.

- I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed.

- If we decide to do 5.0.3, it could be done from the 'release' branch.

Cheers,
--
Sergio Ahumada
Release Engineer - Digia, Qt

[Shaw Andy]

> Making of Qt 5.1 minor release will soon start:
>
> - Plan is to move 'dev' into 'stable' branch on March 19th.
>
> - After March 19th any changes that are required to get in for 5.1
> need to be pushed into 'stable' branch. So if your needed changes don't
> make it today,
> please wait after the merge is done and re-target it.
>
> - I haven't planed to create any branch yet for commits already in 'stable' and
> not in 'release'. So speak up if this is needed.
>
> - If we decide to do 5.0.3, it could be done from the 'release' branch.

Considering that people have been developing on stable on the basis that it is in fact 5.0.x, I think we should at least make sure that those changes end up somewhere in case we do a 5.0.3 release for whatever reason. Rather than lose those changes because we merged, could a read only branch be created from the current stable and then merge that into release should a 5.0.3 release happen? So no more work would be done for 5.0.x unless it is decided to make a 5.0.3 release.

Andy

[Sean Harmer]

On Monday 18 March 2013 10:27:45 Shaw Andy wrote:
> > Making of Qt 5.1 minor release will soon start:
> >
> > - Plan is to move 'dev' into 'stable' branch on March 19th.
> >
> > - After March 19th any changes that are required to get in for 5.1
> >
> > need to be pushed into 'stable' branch. So if your needed changes don't
> >
> > make it today,
> >
> > please wait after the merge is done and re-target it.
> >
> > - I haven't planed to create any branch yet for commits already in
> > 'stable' and not in 'release'. So speak up if this is needed.
> >
> > - If we decide to do 5.0.3, it could be done from the 'release' branch.
>
> Considering that people have been developing on stable on the basis that it
> is in fact 5.0.x, I think we should at least make sure that those changes
> end up somewhere in case we do a 5.0.3 release for whatever reason. Rather
> than lose those changes because we merged, could a read only branch be
> created from the current stable and then merge that into release should a
> 5.0.3 release happen? So no more work would be done for 5.0.x unless it is
> decided to make a 5.0.3 release.

I agree. 5.0.3 may never happen but this is good practise and a sensible
precaution to take in case we do decide to release one.

Cheers,

Sean
--
Dr Sean Harmer | ***@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[Turunen Tuukka]

On 18.3.2013 12.42, "Sean Harmer" <***@kdab.com> wrote:

>On Monday 18 March 2013 10:27:45 Shaw Andy wrote:
>> > Making of Qt 5.1 minor release will soon start:
>> >
>> > - Plan is to move 'dev' into 'stable' branch on March 19th.
>> >
>> > - After March 19th any changes that are required to get in for 5.1
>> >
>> > need to be pushed into 'stable' branch. So if your needed changes
>>don't
>> >
>> > make it today,
>> >
>> > please wait after the merge is done and re-target it.
>> >
>> > - I haven't planed to create any branch yet for commits already in
>> > 'stable' and not in 'release'. So speak up if this is needed.
>> >
>> > - If we decide to do 5.0.3, it could be done from the 'release'
>>branch.
>>
>> Considering that people have been developing on stable on the basis
>>that it
>> is in fact 5.0.x, I think we should at least make sure that those
>>changes
>> end up somewhere in case we do a 5.0.3 release for whatever reason.
>>Rather
>> than lose those changes because we merged, could a read only branch be
>> created from the current stable and then merge that into release should
>>a
>> 5.0.3 release happen? So no more work would be done for 5.0.x unless it
>>is
>> decided to make a 5.0.3 release.
>
>I agree. 5.0.3 may never happen but this is good practise and a sensible
>precaution to take in case we do decide to release one.

It is not very likely that someone decides to stay with 5.0.x, so whatever
we do should be such that encourages users to get to 5.1.x, thus we do not
need 5.0.x to overlap with 5.1.x as we do with 4.8.x.

As you know 5.0.2 is in the works to be out soon and will introduce a
great number of fixes over 5.0.1. I hope they are enough to carry us to
5.1.0.

I see three reasons for making 5.0.3:

-> A security issue mandating immediate fix release => that can and should
be done on top of 5.0.2 with a minimal amount of fixes directly in the
release branch
-> A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to
have something usable => that can and should be done in the release branch
with very small amount of changes to 5.0.2
-> Severe problems in getting 5.1 out increasing the need of getting 5.0.3
=> In this situation everyone doing releases is working with 5.1, so even
if there is a need, we can not make 5.0.3 without causing even more
problems to 5.1 (please not that this is a theoretical situation, I do not
expect any problems with 5.1)

Thus I think that it is enough to tag the stable branch before we merge
from dev. In case we ever need to get the situation before, it can be done
easily.

Yours,

Tuukka

[Sean Harmer]

On Monday 18 March 2013 11:00:57 Turunen Tuukka wrote:
> On 18.3.2013 12.42, "Sean Harmer" <***@kdab.com> wrote:
> >On Monday 18 March 2013 10:27:45 Shaw Andy wrote:
> >> > Making of Qt 5.1 minor release will soon start:
> >> >
> >> > - Plan is to move 'dev' into 'stable' branch on March 19th.
> >> >
> >> > - After March 19th any changes that are required to get in for 5.1
> >> >
> >> > need to be pushed into 'stable' branch. So if your needed changes
> >>
> >>don't
> >>
> >> > make it today,
> >> >
> >> > please wait after the merge is done and re-target it.
> >> >
> >> > - I haven't planed to create any branch yet for commits already in
> >> > 'stable' and not in 'release'. So speak up if this is needed.
> >> >
> >> > - If we decide to do 5.0.3, it could be done from the 'release'
> >>
> >>branch.
> >>
> >> Considering that people have been developing on stable on the basis
> >>
> >>that it
> >>
> >> is in fact 5.0.x, I think we should at least make sure that those
> >>
> >>changes
> >>
> >> end up somewhere in case we do a 5.0.3 release for whatever reason.
> >>
> >>Rather
> >>
> >> than lose those changes because we merged, could a read only branch be
> >> created from the current stable and then merge that into release should
> >>
> >>a
> >>
> >> 5.0.3 release happen? So no more work would be done for 5.0.x unless it
> >>
> >>is
> >>
> >> decided to make a 5.0.3 release.
> >
> >I agree. 5.0.3 may never happen but this is good practise and a sensible
> >precaution to take in case we do decide to release one.
>
> It is not very likely that someone decides to stay with 5.0.x, so whatever
> we do should be such that encourages users to get to 5.1.x, thus we do not
> need 5.0.x to overlap with 5.1.x as we do with 4.8.x.
>
> As you know 5.0.2 is in the works to be out soon and will introduce a
> great number of fixes over 5.0.1. I hope they are enough to carry us to
> 5.1.0.
>
> I see three reasons for making 5.0.3:
>
> -> A security issue mandating immediate fix release => that can and should
> be done on top of 5.0.2 with a minimal amount of fixes directly in the
> release branch
> -> A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3 to
> have something usable => that can and should be done in the release branch
> with very small amount of changes to 5.0.2
> -> Severe problems in getting 5.1 out increasing the need of getting 5.0.3
> => In this situation everyone doing releases is working with 5.1, so even
> if there is a need, we can not make 5.0.3 without causing even more
> problems to 5.1 (please not that this is a theoretical situation, I do not
> expect any problems with 5.1)
>
> Thus I think that it is enough to tag the stable branch before we merge
> from dev. In case we ever need to get the situation before, it can be done
> easily.

Since you list several reasons why we may well need a Qt 5.0.3, then why not
do it properly and just make a branch as Andy suggests? What is the downside?

Cheers,

Sean

--
Dr Sean Harmer | ***@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[Knoll Lars]

On 3/18/13 12:04 PM, "Sean Harmer" <***@kdab.com> wrote:

>On Monday 18 March 2013 11:00:57 Turunen Tuukka wrote:
>> On 18.3.2013 12.42, "Sean Harmer" <***@kdab.com> wrote:
>> >On Monday 18 March 2013 10:27:45 Shaw Andy wrote:
>> >> > Making of Qt 5.1 minor release will soon start:
>> >> >
>> >> > - Plan is to move 'dev' into 'stable' branch on March 19th.
>> >> >
>> >> > - After March 19th any changes that are required to get in for 5.1
>> >> >
>> >> > need to be pushed into 'stable' branch. So if your needed changes
>> >>
>> >>don't
>> >>
>> >> > make it today,
>> >> >
>> >> > please wait after the merge is done and re-target it.
>> >> >
>> >> > - I haven't planed to create any branch yet for commits already in
>> >> > 'stable' and not in 'release'. So speak up if this is needed.
>> >> >
>> >> > - If we decide to do 5.0.3, it could be done from the 'release'
>> >>
>> >>branch.
>> >>
>> >> Considering that people have been developing on stable on the basis
>> >>
>> >>that it
>> >>
>> >> is in fact 5.0.x, I think we should at least make sure that those
>> >>
>> >>changes
>> >>
>> >> end up somewhere in case we do a 5.0.3 release for whatever reason.
>> >>
>> >>Rather
>> >>
>> >> than lose those changes because we merged, could a read only branch
>>be
>> >> created from the current stable and then merge that into release
>>should
>> >>
>> >>a
>> >>
>> >> 5.0.3 release happen? So no more work would be done for 5.0.x unless
>>it
>> >>
>> >>is
>> >>
>> >> decided to make a 5.0.3 release.
>> >
>> >I agree. 5.0.3 may never happen but this is good practise and a
>>sensible
>> >precaution to take in case we do decide to release one.
>>
>> It is not very likely that someone decides to stay with 5.0.x, so
>>whatever
>> we do should be such that encourages users to get to 5.1.x, thus we do
>>not
>> need 5.0.x to overlap with 5.1.x as we do with 4.8.x.
>>
>> As you know 5.0.2 is in the works to be out soon and will introduce a
>> great number of fixes over 5.0.1. I hope they are enough to carry us to
>> 5.1.0.
>>
>> I see three reasons for making 5.0.3:
>>
>> -> A security issue mandating immediate fix release => that can and
>>should
>> be done on top of 5.0.2 with a minimal amount of fixes directly in the
>> release branch
>> -> A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3
>>to
>> have something usable => that can and should be done in the release
>>branch
>> with very small amount of changes to 5.0.2
>> -> Severe problems in getting 5.1 out increasing the need of getting
>>5.0.3
>> => In this situation everyone doing releases is working with 5.1, so
>>even
>> if there is a need, we can not make 5.0.3 without causing even more
>> problems to 5.1 (please not that this is a theoretical situation, I do
>>not
>> expect any problems with 5.1)
>>
>> Thus I think that it is enough to tag the stable branch before we merge
>> from dev. In case we ever need to get the situation before, it can be
>>done
>> easily.
>
>Since you list several reasons why we may well need a Qt 5.0.3, then why
>not
>do it properly and just make a branch as Andy suggests? What is the
>downside?

If required, we can always create that branch later on (ie. branch from
the latest sha1 in stable before we merged dev back to stable). Is there a
real reason why we should do it now? I don't really see one.

Cheers,
Lars

[Sean Harmer]

On Monday 18 March 2013 11:29:54 Knoll Lars wrote:
> On 3/18/13 12:04 PM, "Sean Harmer" <***@kdab.com> wrote:
> >On Monday 18 March 2013 11:00:57 Turunen Tuukka wrote:
> >> On 18.3.2013 12.42, "Sean Harmer" <***@kdab.com> wrote:
> >> >On Monday 18 March 2013 10:27:45 Shaw Andy wrote:
> >> >> > Making of Qt 5.1 minor release will soon start:
> >> >> >
> >> >> > - Plan is to move 'dev' into 'stable' branch on March 19th.
> >> >> >
> >> >> > - After March 19th any changes that are required to get in for 5.1
> >> >> >
> >> >> > need to be pushed into 'stable' branch. So if your needed changes
> >> >>
> >> >>don't
> >> >>
> >> >> > make it today,
> >> >> >
> >> >> > please wait after the merge is done and re-target it.
> >> >> >
> >> >> > - I haven't planed to create any branch yet for commits already in
> >> >> > 'stable' and not in 'release'. So speak up if this is needed.
> >> >> >
> >> >> > - If we decide to do 5.0.3, it could be done from the 'release'
> >> >>
> >> >>branch.
> >> >>
> >> >> Considering that people have been developing on stable on the basis
> >> >>
> >> >>that it
> >> >>
> >> >> is in fact 5.0.x, I think we should at least make sure that those
> >> >>
> >> >>changes
> >> >>
> >> >> end up somewhere in case we do a 5.0.3 release for whatever reason.
> >> >>
> >> >>Rather
> >> >>
> >> >> than lose those changes because we merged, could a read only branch
> >>
> >>be
> >>
> >> >> created from the current stable and then merge that into release
> >>
> >>should
> >>
> >> >>a
> >> >>
> >> >> 5.0.3 release happen? So no more work would be done for 5.0.x unless
> >>
> >>it
> >>
> >> >>is
> >> >>
> >> >> decided to make a 5.0.3 release.
> >> >
> >> >I agree. 5.0.3 may never happen but this is good practise and a
> >>
> >>sensible
> >>
> >> >precaution to take in case we do decide to release one.
> >>
> >> It is not very likely that someone decides to stay with 5.0.x, so
> >>
> >>whatever
> >>
> >> we do should be such that encourages users to get to 5.1.x, thus we do
> >>
> >>not
> >>
> >> need 5.0.x to overlap with 5.1.x as we do with 4.8.x.
> >>
> >> As you know 5.0.2 is in the works to be out soon and will introduce a
> >> great number of fixes over 5.0.1. I hope they are enough to carry us to
> >> 5.1.0.
> >>
> >> I see three reasons for making 5.0.3:
> >>
> >> -> A security issue mandating immediate fix release => that can and
> >>
> >>should
> >>
> >> be done on top of 5.0.2 with a minimal amount of fixes directly in the
> >> release branch
> >> -> A 'brown paper bag' issue in 5.0.2 mandating fix and making or 5.0.3
> >>
> >>to
> >>
> >> have something usable => that can and should be done in the release
> >>
> >>branch
> >>
> >> with very small amount of changes to 5.0.2
> >> -> Severe problems in getting 5.1 out increasing the need of getting
> >>
> >>5.0.3
> >>
> >> => In this situation everyone doing releases is working with 5.1, so
> >>
> >>even
> >>
> >> if there is a need, we can not make 5.0.3 without causing even more
> >> problems to 5.1 (please not that this is a theoretical situation, I do
> >>
> >>not
> >>
> >> expect any problems with 5.1)
> >>
> >> Thus I think that it is enough to tag the stable branch before we merge
> >> from dev. In case we ever need to get the situation before, it can be
> >>
> >>done
> >>
> >> easily.
> >
> >Since you list several reasons why we may well need a Qt 5.0.3, then why
> >not
> >do it properly and just make a branch as Andy suggests? What is the
> >downside?
>
> If required, we can always create that branch later on (ie. branch from
> the latest sha1 in stable before we merged dev back to stable). Is there a
> real reason why we should do it now? I don't really see one.

It's no big deal. It just seemed more logical to me to create a 5.0 branch
than a tag like "branch_from_here_if_5.0.3_is_needed". As long as it is
possible to provide for the potential of a future release in the 5.0.x series,
then whether it is done via branching or tagging now doesn't really matter.

Cheers,

Sean
--
Dr Sean Harmer | ***@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[Giuseppe D'Angelo]

On 18 March 2013 11:24, Ahumada Sergio <***@digia.com> wrote:
>
> Making of Qt 5.1 minor release will soon start:
>
> - Plan is to move 'dev' into 'stable' branch on March 19th.
>
> - After March 19th any changes that are required to get in for 5.1
> need to be pushed into 'stable' branch. So if your needed changes don't make it today,
> please wait after the merge is done and re-target it.

I don't like this very much. We've been running late with the merge,
but giving people a 1 day notice (without prior warnings) seems
unfair. And, I think stable should never get broken w.r.t. forward
binary compatibility, unless at very specific points -- i.e. when we
merge -dev into it. The branch guidelines indeed specify that we
should freeze and stabilize -dev, not -stable, and release 5.1 alpha
out of -dev, not -stable, so that eventual API/ABI fixes to 5.1
material go into -dev. We should merge only when in -beta quality.

--
Giuseppe D'Angelo

[Ahumada Sergio]

On 18 March 2013 11:24, Ahumada Sergio <***@digia.com> wrote:
>>
>> Making of Qt 5.1 minor release will soon start:
>>
>> - Plan is to move 'dev' into 'stable' branch on March 19th.
>>
>> - After March 19th any changes that are required to get in for 5.1
>> need to be pushed into 'stable' branch. So if your needed changes don't make it today,
>> please wait after the merge is done and re-target it.
>
> I don't like this very much. We've been running late with the merge,
> but giving people a 1 day notice (without prior warnings) seems
> unfair. And, I think stable should never get broken w.r.t. forward
> binary compatibility, unless at very specific points -- i.e. when we
> merge -dev into it. The branch guidelines indeed specify that we
> should freeze and stabilize -dev, not -stable, and release 5.1 alpha
> out of -dev, not -stable, so that eventual API/ABI fixes to 5.1
> material go into -dev. We should merge only when in -beta quality.

Hi,

The warning was giving a month ago http://lists.qt-project.org/pipermail/development/2013-February/009838.html

So this one extra day (or two) is just a friendly reminder.

About the tag, one could argue that making the tag (and alpha release) before or after the merge might be the same.

Cheers,
--
Sergio Ahumada
Release Engineer - Digia, Qt

[Giuseppe D'Angelo]

On 18 March 2013 14:22, Ahumada Sergio <***@digia.com> wrote:
> About the tag, one could argue that making the tag (and alpha release) before or after the merge might be the same.

This is not only about making the 5.1.0-alpha1 tag. This is about not
breaking forward binary compatibility in stable unless extraordinary
circumstances. The branch guidelines imply that we should not merge
unless we are (almost) in beta quality, see
http://i.imgur.com/N1jVW.png (from
http://qt-project.org/wiki/Branch-Guidelines , 2nd picture).

We can declare dev frozen and not accept any new
significant/destabilizing feature, but I disagree on the point that we
should retarget small new features (pending, not yet +2d) to stable,
as well as getting the first round of API feedback (which could mean
API/ABI breaks) in stable. (That of course could still happen after a
beta released from -stable, but it would probably require much
stronger arguments in order to go through.)

Just my 2c,
--
Giuseppe D'Angelo

[Stephen Kelly]

On Monday, March 18, 2013 13:22:32 Ahumada Sergio wrote:
> >> - Plan is to move 'dev' into 'stable' branch on March 19th.
> >>
> >> - After March 19th any changes that are required to get in for 5.1

> http://lists.qt-project.org/pipermail/development/2013-February/009838.html

Is there any concern about how this is affected by integrations of qt5.git?

https://codereview.qt-project.org/#q,status:open+project:qt/qt5,n,z

For example, qtsensors is not yet part of it.

Thanks,

--
Stephen Kelly <***@kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany [phone] || Sweden (HQ) [phone]
KDAB - Qt Experts - Platform-Independent Software Solutions

[Oswald Buddenhagen]

On Mon, Mar 18, 2013 at 10:24:23AM +0000, Ahumada Sergio wrote:
> Hi,
>
> Making of Qt 5.1 minor release will soon start:
>
> - Plan is to move 'dev' into 'stable' branch on March 19th.
>
i'd like to raise a formal objection.

CI was virtually unusable for two weeks now.
due to that there is a completely unreasonable backlog of changes meant
for 5.1 now. it makes no sense to re-target (or even deny them) due to
infrastructure problems.
also, we didn't have a single qt5.git integration in several weeks now.
that means that there is a fair amount of uncertainty involved (well, in
fact, i know that it's broken - my half-integrated patch series
contributes to that).

consequently we should delay the freeze by at least one week.

> - I haven't planed to create any branch yet for commits already in 'stable' and not in 'release'. So speak up if this is needed.
>
in fact, thiago and me already decided that we'll create an old/5.0
branch from stable right before we merge dev.

[Knoll Lars]

On 3/18/13 3:22 PM, "Oswald Buddenhagen" <***@digia.com>
wrote:

>On Mon, Mar 18, 2013 at 10:24:23AM +0000, Ahumada Sergio wrote:
>> Hi,
>>
>> Making of Qt 5.1 minor release will soon start:
>>
>> - Plan is to move 'dev' into 'stable' branch on March 19th.
>>
>i'd like to raise a formal objection.
>
>CI was virtually unusable for two weeks now.
>due to that there is a completely unreasonable backlog of changes meant
>for 5.1 now. it makes no sense to re-target (or even deny them) due to
>infrastructure problems.

We have said that we'll move to time based releases. Should we stop this
because we aren't yet good enough in controlling our systems? I don't
think so. It might feel unfair to some people, but we've had these
discussions about some features missing the deadline every single minor
release.

Now if there are one or two features that are vital to make Qt 5.1
possible, we can discuss exceptions for those. But then we need to make
sure they go in in the next two days. Which features would these be?

>also, we didn't have a single qt5.git integration in several weeks now.
>that means that there is a fair amount of uncertainty involved (well, in
>fact, i know that it's broken - my half-integrated patch series
>contributes to that).

Yes, that is a concern for me as well.

If you're already claiming responsibility for at least part of the
problem, could you then help getting it fixed?
>
>consequently we should delay the freeze by at least one week.
>
>> - I haven't planed to create any branch yet for commits already in
>>'stable' and not in 'release'. So speak up if this is needed.
>>
>in fact, thiago and me already decided that we'll create an old/5.0
>branch from stable right before we merge dev.

Not that I'm principally opposed to this, but please remember proper
process: These should at least get discussed on this ML, not just get
decided by two people and then announced.

Lars

[Thomas McGuire]

Hi,

On Monday 18 March 2013 16:18:07 Knoll Lars wrote:
> >On Mon, Mar 18, 2013 at 10:24:23AM +0000, Ahumada Sergio wrote:
> >> Hi,
> >>
> >>
> >>
> >> Making of Qt 5.1 minor release will soon start:
> >>
> >>
> >> - Plan is to move 'dev' into 'stable' branch on March 19th.
> >>
> >>
> >
> >i'd like to raise a formal objection.
> >
> >CI was virtually unusable for two weeks now.
> >due to that there is a completely unreasonable backlog of changes meant
> >for 5.1 now. it makes no sense to re-target (or even deny them) due to
> >infrastructure problems.
>
> We have said that we'll move to time based releases. Should we stop this
> because we aren't yet good enough in controlling our systems? I don't
> think so. It might feel unfair to some people, but we've had these
> discussions about some features missing the deadline every single minor
> release.
>
> Now if there are one or two features that are vital to make Qt 5.1
> possible, we can discuss exceptions for those.

QtSensors needs to be added to qt5.git, but couldn't yet, due to CI failures.
See https://codereview.qt-project.org/#change,48905.

Regards,
Thomas
--
Thomas McGuire | ***@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany [phone], Sweden (HQ) [phone]
KDAB - Qt Experts - Platform-independent software solutions

[Laszlo Papp]

On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>wrote:

> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
> failures.
> See https://codereview.qt-project.org/#change,48905.
>

+ QtSerialPort: https://codereview.qt-project.org/#change,49157

Laszlo

[Thiago Macieira]

On segunda-feira, 18 de março de 2013 15.18.07, Knoll Lars wrote:
> We have said that we'll move to time based releases. Should we stop this
> because we aren't yet good enough in controlling our systems? I don't
> think so. It might feel unfair to some people, but we've had these
> discussions about some features missing the deadline every single minor
> release.
>
> Now if there are one or two features that are vital to make Qt 5.1
> possible, we can discuss exceptions for those. But then we need to make
> sure they go in in the next two days. Which features would these be?

I know of only the QUrlPathInfo and the timezone features, plus minor API
changes, for QtCore. The former is something that had been lost in my large
dashboard until last week, and John's changes were too big to review while I
was at a conference.

> >> - I haven't planed to create any branch yet for commits already in
> >>
> >>'stable' and not in 'release'. So speak up if this is needed.
> >
> >in fact, thiago and me already decided that we'll create an old/5.0
> >branch from stable right before we merge dev.
>
> Not that I'm principally opposed to this, but please remember proper
> process: These should at least get discussed on this ML, not just get
> decided by two people and then announced.

I thought it was discussed on the mailing list.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Stephen Kelly]

On Monday, March 18, 2013 10:36:27 Thiago Macieira wrote:
> I know of only the QUrlPathInfo and the timezone features, plus minor API
> changes, for QtCore. The former is something that had been lost in my large
> dashboard until last week, and John's changes were too big to review while
> I was at a conference.

I think I'd prefer not adding the timezone stuff until 5.2. It will need to
change a lot for that release anyway (implementation wise) as only then it
will get the ICU support, right? Will that also be a behavior change in eg,
how datetimes are parsed? Is there also a behavior change with the existing
patches? How well is that tested with code external to qtbase? Why rush it in
in the week we want to branch for alpha? The chances of it struggling through
CI itself are pretty high.

Thanks,

--
Stephen Kelly <***@kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany [phone] || Sweden (HQ) [phone]
KDAB - Qt Experts - Platform-Independent Software Solutions

[Sorvig Morten]

On Mar 18, 2013, at 4:18 PM, Knoll Lars <***@digia.com> wrote:

> On 3/18/13 3:22 PM, "Oswald Buddenhagen" <***@digia.com>
> wrote:
>>>
>> i'd like to raise a formal objection.
>>
>> CI was virtually unusable for two weeks now.
>> due to that there is a completely unreasonable backlog of changes meant
>> for 5.1 now. it makes no sense to re-target (or even deny them) due to
>> infrastructure problems.
>
> We have said that we'll move to time based releases. Should we stop this
> because we aren't yet good enough in controlling our systems? I don't
> think so. It might feel unfair to some people, but we've had these
> discussions about some features missing the deadline every single minor
> release.

Well, a central component of time-based releases is that it's actually possible to plan your work to meet the deadline.

My current rate is spending several days per change. We should stop and make our systems usable.


>
> Now if there are one or two features that are vital to make Qt 5.1
> possible, we can discuss exceptions for those. But then we need to make
> sure they go in in the next two days. Which features would these be?

I would like to get https://codereview.qt-project.org/#change,49452 in to support HighDpi on Mac. I have several changes after that but they are all bug fixes and can go into stable.

But how can I make sure it goes in the next two days?

Morten

[Knoll Lars]

On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:

>On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>wrote:
>
>QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>failures.
>See https://codereview.qt-project.org/#change,48905.
>
>
>
>+ QtSerialPort: https://codereview.qt-project.org/#change,49157

+ Mac and X11 extras. Yes, these are known.

In addition, we need to get qt5.git updated to recent sha1's of all qt
modules.

Cheers,
Lars

[Jake Thomas Petroules]

Don't you mean Mac and Windows? I thought X11 was added a while ago.

Sent from my iPhone

On Mar 18, 2013, at 12:05 PM, Knoll Lars <***@digia.com> wrote:

> On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:
>
>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>> wrote:
>>
>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>> failures.
>> See https://codereview.qt-project.org/#change,48905.
>>
>>
>>
>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
>
> + Mac and X11 extras. Yes, these are known.
>
> In addition, we need to get qt5.git updated to recent sha1's of all qt
> modules.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Jake Thomas Petroules]

Don't you mean Mac and Windows? I thought X11 was added a while ago.
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: ***@petroules.com

On Mar 18, 2013, at 12:05 PM, Knoll Lars <***@digia.com> wrote:

> On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:
>
>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>> wrote:
>>
>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>> failures.
>> See https://codereview.qt-project.org/#change,48905.
>>
>>
>>
>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
>
> + Mac and X11 extras. Yes, these are known.
>
> In addition, we need to get qt5.git updated to recent sha1's of all qt
> modules.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Sorvig Morten]

On Mar 18, 2013, at 5:05 PM, Knoll Lars <***@digia.com> wrote:

> On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:
>
>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>> wrote:
>>
>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>> failures.
>> See https://codereview.qt-project.org/#change,48905.
>>
>>
>>
>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
>
> + Mac and X11 extras. Yes, these are known.


QtMacExtras is currently not in a releasable state. It's missing documentation, some examples and needs some general polish and bug fixes.

I think we also need to resolve the "native type" converters discussion to know which API's goes into QtMacExtras.

Since we are running out of time for 5.1 - should we postpone it to 5.2?

Morten

[Jake Thomas Petroules]

I think we should just postpone the extras 'till 5.2, yes.

QtWindowsExtras needs a ton more work - Ivan Vizir's big Windows 7 features commit is still not ready and likely won't for a while. I believe he said he is planning a second commit with more of them since thumbnail toolbars were left out of his first one for reasons of time. Like Morten said, QtMacExtras needs a lot more polish too. Unfortunately he and I are the only ones working on it.

As for the operators, I remember there was a discussion on IRC suggesting we simply declare the methods and operators and forward declare the types necessary in QtCore/QtGui, and implement them in QtWindowsExtras/QtMacExtras. Then the former need not link to any additional libraries.

My vote is for constructors and conversion operators on (the all caps types are Win32 types):

QString <=> NSString
QPoint <=> CGPoint, NSPoint, POINT
QSize <=> CGSize, NSSize, (there's no `SIZE` afaik)
QRect <=> CGRect, NSSize, SIZE
QMargins <=> MARGINS

Darwin has a lot of image types. UIImage converters are not strictly necessary since UIImage has easy methods to/from CGImageRef since iOS 2.0. However, something like: `inline UIImage* QImageToUIImage(const QImage &image) { return [UIImage imageWithCGImage:QImageToCGImage(image)]; }` would save typing so I think we should add them anyways. Similar story with CIImage (except there's no CIImage -> CGImageRef and can't be from the looks of the API).

QIcon <=> HICON
QImage/QPixmap <=> HBITMAP, CGImageRef, NSImage, UIImage, CIImage
QString <=> CFStringRef, NSString

Anything else?

After all this, though, I think we should still implement the constructors and operators in terms of free functions so that the converters are also usable by Qt 4.

Are there any objections to this? Can we start adding constructors and operators to QtCore and QtGui?
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: ***@petroules.com

On Mar 19, 2013, at 2:52 AM, Sorvig Morten <***@digia.com> wrote:

>
> On Mar 18, 2013, at 5:05 PM, Knoll Lars <***@digia.com> wrote:
>
>> On 3/18/13 4:58 PM, "Laszlo Papp" <***@kde.org> wrote:
>>
>>> On Mon, Mar 18, 2013 at 3:52 PM, Thomas McGuire <***@kdab.com>
>>> wrote:
>>>
>>> QtSensors needs to be added to qt5.git, but couldn't yet, due to CI
>>> failures.
>>> See https://codereview.qt-project.org/#change,48905.
>>>
>>>
>>>
>>> + QtSerialPort: https://codereview.qt-project.org/#change,49157
>>
>> + Mac and X11 extras. Yes, these are known.
>
>
> QtMacExtras is currently not in a releasable state. It's missing documentation, some examples and needs some general polish and bug fixes.
>
> I think we also need to resolve the "native type" converters discussion to know which API's goes into QtMacExtras.
>
> Since we are running out of time for 5.1 - should we postpone it to 5.2?
>
> Morten
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Knoll Lars]

On 3/18/13 6:36 PM, "Thiago Macieira" <***@intel.com> wrote:

>On segunda-feira, 18 de março de 2013 15.18.07, Knoll Lars wrote:
>> We have said that we'll move to time based releases. Should we stop this
>> because we aren't yet good enough in controlling our systems? I don't
>> think so. It might feel unfair to some people, but we've had these
>> discussions about some features missing the deadline every single minor
>> release.
>>
>> Now if there are one or two features that are vital to make Qt 5.1
>> possible, we can discuss exceptions for those. But then we need to make
>> sure they go in in the next two days. Which features would these be?
>
>I know of only the QUrlPathInfo and the timezone features, plus minor API
>changes, for QtCore. The former is something that had been lost in my
>large
>dashboard until last week, and John's changes were too big to review
>while I
>was at a conference.

Yes. I doubt we'll get timezone done in time though, unless you're happy
with the API as it is now.

The file selectors would be very helpful for declarative. Getting it in is
important, because I'd like to set the standard before everybody does his
own. I think BlackBerry might also need it to move over to Qt 5 at some
point

>
>> >> - I haven't planed to create any branch yet for commits already in
>> >>
>> >>'stable' and not in 'release'. So speak up if this is needed.
>> >
>> >in fact, thiago and me already decided that we'll create an old/5.0
>> >branch from stable right before we merge dev.
>>
>> Not that I'm principally opposed to this, but please remember proper
>> process: These should at least get discussed on this ML, not just get
>> decided by two people and then announced.
>
>I thought it was discussed on the mailing list.

Ok, I might have missed it. The way Ossi put it, it sounded like an IRC
discussion.

Cheers,
Lars

[Alan Alpert]

On Mon, Mar 18, 2013 at 12:31 PM, Knoll Lars <***@digia.com> wrote:
> On 3/18/13 6:36 PM, "Thiago Macieira" <***@intel.com> wrote:
>
>>On segunda-feira, 18 de março de 2013 15.18.07, Knoll Lars wrote:
>>> We have said that we'll move to time based releases. Should we stop this
>>> because we aren't yet good enough in controlling our systems? I don't
>>> think so. It might feel unfair to some people, but we've had these
>>> discussions about some features missing the deadline every single minor
>>> release.
>>>
>>> Now if there are one or two features that are vital to make Qt 5.1
>>> possible, we can discuss exceptions for those. But then we need to make
>>> sure they go in in the next two days. Which features would these be?
>>
>>I know of only the QUrlPathInfo and the timezone features, plus minor API
>>changes, for QtCore. The former is something that had been lost in my
>>large
>>dashboard until last week, and John's changes were too big to review
>>while I
>>was at a conference.
>
> Yes. I doubt we'll get timezone done in time though, unless you're happy
> with the API as it is now.
>
> The file selectors would be very helpful for declarative. Getting it in is
> important, because I'd like to set the standard before everybody does his
> own. I think BlackBerry might also need it to move over to Qt 5 at some
> point

BlackBerry kind of "needs" it, in that if they don't have it then
they'll continue to do their own highly incompatible thing after
switching to Qt 5. Which is bad enough for everyone that we can say
it's needed.

My current concern with QFileSelectors is the discussion. There was a
discussion on the mailing list months ago where everyone involved came
to a rough consensus. Unfortunately it appears that not all interested
parties were involved in this discussion, so we get to go through it
again now in gerrit. In these circumstances, should the discussion
move back to the ML? Or do we move the conversation to the review
comments and assume interested parties are watching the change? In
either case, how can we give the discussion enough time when it sparks
back up right before merge?

--
Alan Alpert

[Thiago Macieira]

On segunda-feira, 18 de março de 2013 19.31.03, Knoll Lars wrote:
> >I know of only the QUrlPathInfo and the timezone features, plus minor API
> >changes, for QtCore. The former is something that had been lost in my
> >large
> >dashboard until last week, and John's changes were too big to review
> >while I
> >was at a conference.
>
> Yes. I doubt we'll get timezone done in time though, unless you're happy
> with the API as it is now.

I'll do my best to review it.

> The file selectors would be very helpful for declarative. Getting it in is
> important, because I'd like to set the standard before everybody does his
> own. I think BlackBerry might also need it to move over to Qt 5 at some
> point

I delegated that because I had no time. Therefore, I will abide by the
decisions of whoever did review it.

I would still like it work for the Mac HighDPI functionality and work with
QFile. I don't want a class in QtCore that can't be used with other QtCore
classes directly.

> >> >in fact, thiago and me already decided that we'll create an old/5.0
> >> >branch from stable right before we merge dev.
> >>
> >> Not that I'm principally opposed to this, but please remember proper
> >> process: These should at least get discussed on this ML, not just get
> >> decided by two people and then announced.
> >
> >I thought it was discussed on the mailing list.
>
> Ok, I might have missed it. The way Ossi put it, it sounded like an IRC
> discussion.

He surprised me too.

And if it was an IRC conclusion, he could have said "we came to the conclusion
that creating old/5.0 is a good idea".

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center