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

[Tuukka Turunen]

Hi,

To be clear, the updated QUIP5 (http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst) says: 

"*strict*
    This period starts when the one after next stable branch is created (for the
    5.9 LTS, the one after next is 5.11). Submitting to the LTS branch directly
    is then no longer possible; changes must be submitted to the stable branch
    and undergo some testing first before being cherry-picked into the LTS
    branch."

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

I think that it is not possible to wait until Qt 5.11.0 is released before going to cherry pick mode for Qt 5.9 LTS and closing (or moving to cherry pick mode) for Qt 5.10. We just do not have enough people and computers to manage all the needed merges in time.  I do understand the opinions that it would be nice to have these open longer, but it is not seen feasible by the persons who actually do the work needed for it. 

Related to LTS releases in general, I believe that strict mode is a good thing. By only cherry picking the important fixes, we reduce the risk of accidentally causing some undesired regressions (in functionality or performance). We do want to continue making more Qt 5.9.x patch level releases, but with slightly reduced pace after Qt 5.9.5 (planned for March).  

I believe that we can achieve two important items by reducing the amount of merges (Jani's original proposal):
	1. Release Qt 5.11 in schedule without a huge stress for the release team at the end
	2. Keep dev in good working shape during H1/18, thus paving the way of having a rock solid Qt 5.12 (LTS) in November

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. 

Yours,

	Tuukka

On 01/02/2018, 13.36, "Development on behalf of Konstantin Tokarev" <development-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of annulen at yandex.ru> wrote:

    
    
    01.02.2018, 14:19, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
    > On Tue, Jan 30, 2018 at 09:38:29PM +0000, Tuukka Turunen wrote:
    >>  The item that has received comments both in favor and against is what
    >>  to do with 5.10 now. I think that instead of closing 5.10, we could
    >>  move it to cherry pick mode, just like Qt 5.9 is. That allows putting
    >>  the necessary fixes there, but reduces the amount of needed merges a
    >>  lot. It also allows to faster get all the fixes merged up to dev,
    >>  which is something we have struggled in the past.
    >
    > that makes no sense at all.
    > firstly, 5.9 is NOT in cherry-pick mode - your own update to quip 5
    > codifies this status quo. i see no reason to revise that decision
    > *again*.
    > secondly, *nobody* is going to cherry-pick to a branch which *could*
    > _hypothetically_ have another patch release, because that would be an
    > epic waste of resources.
    > thirdly, let me point out that cherry-picking *delays* patch releases,
    > because it implies that a commit must have already integrated into a
    > more current branch before it can hit the release branch (deviating from
    > that principle is just plain stupid), which in the context of our
    > infrastructure makes it a poor choice for recent/active branches.
    
    Only in case when cherry-picked patches are release blockers, otherwise
    they just don't go in if they miss schedule.
    
    I guess the idea behind this proposal is that we improve quality of dev and
    5.11 by sacrificing comprehensiveness of 5.6, 5.9, and 5.10. Multi-level
    merges combined with overall CI instability lead to huge delays for patches
    to reach dev, as a result people work on stable branches or maintain their
    own, which in turn leaves us with worse baseline when next releases' branch
    is started from dev.
    
    >
    > so no, this just isn't an option.
    > _______________________________________________
    > Development mailing list
    > Development at qt-project.org
    > http://lists.qt-project.org/mailman/listinfo/development
    
    -- 
    Regards,
    Konstantin
    
    _______________________________________________
    Development mailing list
    Development at qt-project.org
    http://lists.qt-project.org/mailman/listinfo/development