Re: [Development] Qt branches & proposal how to continue with those

2018-02-05 Thread Jani Heikkinen 
Hi,

So the decision how to proceed is done. Let's give everyone a while to finalize 
ongoing tasks and put the decision in effect after a week. 

So from 12.2.2018 ->
   - '5.9' will be in cherry-pick mode
   - '5.10' will be closed

We will make sure final merges from '5.9' -> '5.10' -> '5.11' will be done 
after that and then there will be merges only from '5.11' -> 'dev'

br,
Jani

From: Development  on 
behalf of Lars Knoll 
Sent: Monday, February 5, 2018 12:35 PM
To: Qt development mailing list
Subject: Re: [Development] Qt branches & proposal how to continue with those

Hi all,

Sorry for being a bit late with answering to this thread. Been first traveling 
and then was down with a flu last week.

Unfortunately, none of the options on the table will be 100% satisfying to 
everybody. This is basically because we have limits on how much work we can or 
should be doing getting different releases out, and different users have 
different preferences with regards to our branches.

I think that we’ll be long term best off, if we move Qt forward as quickly as 
we can. Qt 5.11 provides some significant new things over 5.10, so in the end 
we should prioritise finalising that branch and getting 5.11.0 out as quickly 
as we can. Less merging will free up people and CI capacity to focus on 5.11 
bug fixing and speed up turn around time to getting qt5.git integrations 
through.

This means we’ll go with something close to option 2b that Ossi outlined below:

* We put 5.9 in cherry-picking mode in line with QUIP 5.
* There is currently no 5.10.2 release planned. The main reason to do one would 
be to be an urgent security update. This means we also leave 5.10 branch behind 
and close it.
* If we have a larger security issue that deserves a release (and not just a 
patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe 
doing a one time merge from 5.9 to 5.10 if we want those fixes as well)
* Instead we put our focus on getting 5.11 out as quickly as we can. Let’s 
branch now, create first alpha and then beta packages as quickly as possible. 
Not having to merge from 5.10 will ease this significantly. Getting 5.11 out 
quick will hopefully also make Webengine not fall too far/long behind upstream 
security patches.

Of course, we continue having regular releases from 5.9, but with it being in 
strict mode, the frequency of releases will maybe drop a bit (from every 6 
weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least 
two patch level releases of 5.11 before 5.12 comes out.

Cheers,
Lars

> On 1 Feb 2018, at 15:53, Oswald Buddenhagen  wrote:
>
> On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
>> So based on this Qt 5.9 should be in cherry pick mode next week. With
>> previous wording it should have been in cherry pick mode from 2.9.2017
>> onwards, which was way too soon (hence the change to QUIP5).
>>
> right.
>
>> What about Qt 5.10.2? This of course needs to be addressed after we
>> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
>> release, I would like to put full focus into getting Qt 5.11.0 out
>> quickly and try to release Qt 5.11.1 in June already.
>>
> yes, but the point is that we can't change the policy retroactively. if
> 5.10.2 is an option, then 5.10 needs to stay open as the default target
> for fixes, and be forward-merged. this leaves us at two merges for a fix
> to reach dev.
> the same delay would occurr if we closed 5.10 and continued to merge
> from 5.9, which is why the discussion which one is more important
> emerged.
>
> this leaves us with three options:
> 1)
> - 5.9 goes to cherry-pick mode, essentially now.
> - 5.10 stays open until 5.11.0 is released.
>   - we should create 5.10.2 before the 5.11.0 release even if we don't
> intent to actually make a release, just so we have a mergable
> target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
> cherry-picks).
> 2)
> - we just declare that there won't be 5.10.2 and close 5.10 after
>   5.10.1. potentially not user-friendly, but we've done it in the
>   past, and while releasing capacity isn't the limiting factor now,
>   forward-merging apparently is.
> 2a) we continue to forward-merge from 5.9.
> 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.
>
> note that 5.10 going to cherry-pick mode is specifically not an option,
> as stated previously.
>
> 1) seems most natural to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list

Re: [Development] Qt branches & proposal how to continue with those

2018-02-05 Thread Lars Knoll 
Hi all,

Sorry for being a bit late with answering to this thread. Been first traveling 
and then was down with a flu last week.

Unfortunately, none of the options on the table will be 100% satisfying to 
everybody. This is basically because we have limits on how much work we can or 
should be doing getting different releases out, and different users have 
different preferences with regards to our branches.

I think that we’ll be long term best off, if we move Qt forward as quickly as 
we can. Qt 5.11 provides some significant new things over 5.10, so in the end 
we should prioritise finalising that branch and getting 5.11.0 out as quickly 
as we can. Less merging will free up people and CI capacity to focus on 5.11 
bug fixing and speed up turn around time to getting qt5.git integrations 
through.

This means we’ll go with something close to option 2b that Ossi outlined below:

* We put 5.9 in cherry-picking mode in line with QUIP 5.
* There is currently no 5.10.2 release planned. The main reason to do one would 
be to be an urgent security update. This means we also leave 5.10 branch behind 
and close it. 
* If we have a larger security issue that deserves a release (and not just a 
patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe 
doing a one time merge from 5.9 to 5.10 if we want those fixes as well)
* Instead we put our focus on getting 5.11 out as quickly as we can. Let’s 
branch now, create first alpha and then beta packages as quickly as possible. 
Not having to merge from 5.10 will ease this significantly. Getting 5.11 out 
quick will hopefully also make Webengine not fall too far/long behind upstream 
security patches.

Of course, we continue having regular releases from 5.9, but with it being in 
strict mode, the frequency of releases will maybe drop a bit (from every 6 
weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least 
two patch level releases of 5.11 before 5.12 comes out.

Cheers,
Lars

> On 1 Feb 2018, at 15:53, Oswald Buddenhagen  wrote:
> 
> On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
>> So based on this Qt 5.9 should be in cherry pick mode next week. With
>> previous wording it should have been in cherry pick mode from 2.9.2017
>> onwards, which was way too soon (hence the change to QUIP5).
>> 
> right.
> 
>> What about Qt 5.10.2? This of course needs to be addressed after we
>> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
>> release, I would like to put full focus into getting Qt 5.11.0 out
>> quickly and try to release Qt 5.11.1 in June already. 
>> 
> yes, but the point is that we can't change the policy retroactively. if
> 5.10.2 is an option, then 5.10 needs to stay open as the default target
> for fixes, and be forward-merged. this leaves us at two merges for a fix
> to reach dev.
> the same delay would occurr if we closed 5.10 and continued to merge
> from 5.9, which is why the discussion which one is more important
> emerged.
> 
> this leaves us with three options:
> 1)
> - 5.9 goes to cherry-pick mode, essentially now.
> - 5.10 stays open until 5.11.0 is released.
>   - we should create 5.10.2 before the 5.11.0 release even if we don't
> intent to actually make a release, just so we have a mergable
> target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
> cherry-picks).
> 2)
> - we just declare that there won't be 5.10.2 and close 5.10 after
>   5.10.1. potentially not user-friendly, but we've done it in the
>   past, and while releasing capacity isn't the limiting factor now,
>   forward-merging apparently is.
> 2a) we continue to forward-merge from 5.9.
> 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.
> 
> note that 5.10 going to cherry-pick mode is specifically not an option,
> as stated previously.
> 
> 1) seems most natural to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt branches & proposal how to continue with those

2018-02-05 Thread Lars Knoll 
Hi all,

Sorry for being a bit late with answering to this thread. Been first traveling 
and then was down with a flu last week.

Unfortunately, none of the options on the table will be 100% satisfying to 
everybody. This is basically because we have limits on how much work we can or 
should be doing getting different releases out, and different users have 
different preferences with regards to our branches.

I think that we’ll be long term best off, if we move Qt forward as quickly as 
we can. Qt 5.11 provides some significant new things over 5.10, so in the end 
we should prioritise finalising that branch and getting 5.11.0 out as quickly 
as we can. Less merging will free up people and CI capacity to focus on 5.11 
bug fixing and speed up turn around time to getting qt5.git integrations 
through.

This means we’ll go with something close to option 2b that Ossi outlined below:

* We put 5.9 in cherry-picking mode in line with QUIP 5.
* There is currently no 5.10.2 release planned. The main reason to do one would 
be to be an urgent security update. This means we also leave 5.10 branch behind 
and close it. 
* If we have a larger security issue that deserves a release (and not just a 
patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe 
doing a one time merge from 5.9 to 5.10 if we want those fixes as well)
* Instead we put our focus on getting 5.11 out as quickly as we can. Let’s 
branch now, create first alpha and then beta packages as quickly as possible. 
Not having to merge from 5.10 will ease this significantly. Getting 5.11 out 
quick will hopefully also make Webengine not fall too far/long behind upstream 
security patches.

Of course, we continue having regular releases from 5.9, but with it being in 
strict mode, the frequency of releases will maybe drop a bit (from every 6 
weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least 
two patch level releases of 5.11 before 5.12 comes out.

Cheers,
Lars

> On 1 Feb 2018, at 15:53, Oswald Buddenhagen  wrote:
> 
> On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
>> So based on this Qt 5.9 should be in cherry pick mode next week. With
>> previous wording it should have been in cherry pick mode from 2.9.2017
>> onwards, which was way too soon (hence the change to QUIP5).
>> 
> right.
> 
>> What about Qt 5.10.2? This of course needs to be addressed after we
>> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
>> release, I would like to put full focus into getting Qt 5.11.0 out
>> quickly and try to release Qt 5.11.1 in June already. 
>> 
> yes, but the point is that we can't change the policy retroactively. if
> 5.10.2 is an option, then 5.10 needs to stay open as the default target
> for fixes, and be forward-merged. this leaves us at two merges for a fix
> to reach dev.
> the same delay would occurr if we closed 5.10 and continued to merge
> from 5.9, which is why the discussion which one is more important
> emerged.
> 
> this leaves us with three options:
> 1)
>  - 5.9 goes to cherry-pick mode, essentially now.
>  - 5.10 stays open until 5.11.0 is released.
>- we should create 5.10.2 before the 5.11.0 release even if we don't
>  intent to actually make a release, just so we have a mergable
>  target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
>  cherry-picks).
> 2)
>  - we just declare that there won't be 5.10.2 and close 5.10 after
>5.10.1. potentially not user-friendly, but we've done it in the
>past, and while releasing capacity isn't the limiting factor now,
>forward-merging apparently is.
>  2a) we continue to forward-merge from 5.9.
>  2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.
> 
> note that 5.10 going to cherry-pick mode is specifically not an option,
> as stated previously.
> 
> 1) seems most natural to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development