[Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Oswald Buddenhagen]

On Tue, Apr 11, 2017 at 07:49:28AM +0200, Tuukka Turunen wrote:
>    Hi,
> 
>    With Qt 5.9 beta released last week, I think we should close 5.8 branch
>    now.
> 
it's done.

as usual, i'm expecting a flurry of retargeting requests (not on this
list! gah).

>    Closing 5.8 will help getting Qt 5.9 out in time by pushing everything
>    directly into 5.9 branch. This is already the case for most items, but
>    some items are still pushed to 5.8 branch causing the need for continuous
>    merges and delaying getting those fixes to 5.9. Running the merges and
>    submodule updates also causes load to the CI, which is away from doing
>    more frequent runs on 5.9 and dev.
> 
>    There has been a lot of discussion about this in the mailing lists, I
>    think the two ones below sum it up quite well.
> 
>    Yours,
> 
>            Tuukka
> 
>    On 13/03/2017, 13.33, "Development on behalf of Oswald Buddenhagen"
>    <development-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of
>    oswald.buddenhagen at qt.io> wrote:
> 
>        On Wed, Mar 01, 2017 at 01:38:47PM +0100, Marc Mutz wrote:
>        > On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote:
>        > > > Let's conclude this topic now by moving on towards 5.9 as Tuukka
>        > > > proposed. After some thinking I also agree that this is the best
>        > > > course of action from where we are right now.
>        > >
>        > > This also implies that bug fixes should now get pushed to the 5.9
>        > > branch and we should close the 5.8 branch soon.
>        >
>        > I disagree. Even if you cannot produce releases from 5.8 anymore,
>        > that's our stable branch.
>        >
>        that may be the case, but doesn't necessarily mean that you need to
>        upstream your fixes there. closing it only affects other users of the
>        5.8 tip who want your fixes. probably not that many.
>       
>        otoh, the branch being open costs CI cycles and causes some forward
>        merging effort, while benefitting a marginal number of people.
>       
>        another point is that most tqtc employees are actually following the
>        management order and are neglecting 5.8 (for two months now), which
>        means that it's by far not as stable as one would want it to be.
>       
>        so i guess it's time to give in and officially close the branch.
>        _______________________________________________
>        Development mailing list
>        Development at qt-project.org
>        [1]http://lists.qt-project.org/mailman/listinfo/development
>       
> 
>    On 01/03/2017, 21.58, "Development on behalf of Thiago Macieira"
>    <development-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of
>    thiago.macieira at intel.com> wrote:
> 
>        Em quarta-feira, 1 de marc,o de 2017, `as 04:38:47 PST, Marc Mutz
>    escreveu:
>        > > This also implies that bug fixes should now get pushed to the 5.9
>    branch
>        > > and we should close the 5.8 branch soon.
>        >
>        > I disagree. Even if you cannot produce releases from 5.8 anymore,
>    that's our
>        > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then*
>    you can
>        > close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6?
>       
>        We usually switch the default branch between the beta and the RC, so
>    the point
>        is moot.
>       
>        5.9 will be considered stable in a couple of weeks, so 5.8 can be
>    closed.
>       
>        --
>        Thiago Macieira - thiago.macieira (AT) intel.com
>          Software Architect - Intel Open Source Technology Center
>       
>        _______________________________________________
>        Development mailing list
>        Development at qt-project.org
>        [2]http://lists.qt-project.org/mailman/listinfo/development
> 
> Links:
> 1. http://lists.qt-project.org/mailman/listinfo/development
> 2. http://lists.qt-project.org/mailman/listinfo/development