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...@qt-project.org on behalf of 
annu...@yandex.ru> wrote:

    
    
    01.02.2018, 14:19, "Oswald Buddenhagen" <oswald.buddenha...@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@qt-project.org
    > http://lists.qt-project.org/mailman/listinfo/development
    
    -- 
    Regards,
    Konstantin
    
    _______________________________________________
    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

Reply via email to