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

[Tuukka Turunen]

Sorry for top posting…

I agree that we should aim to make typically 2 patch releases for regular Qt release and more for LTS release.

Lately we have managed to do only one patch release and in case of 5.7 it took 6 months from the .0 release.

This is not good at all. 

We need to the infra and processes to make it easier to do patch releases. Infra is now being improved, although work will be continuous effort. Processes is something being discussed in the branch guidelines QUIP. The amount of changes in a patch release affects to the work needed to polish it. I think we have had tendency to put too many things into patch releases, which causes also risk of breakages to go up.

Yours,

	Tuukka


On 15/02/2017, 14.39, "Releasing on behalf of Torben Dannhauer" <releasing-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of torben at dannhauer.info> wrote:

    
    Zitat von Roland Winklmeier <roland.m.winklmeier at gmail.com>:
    
    > 2017-02-15 12:52 GMT+01:00 Shawn Rutledge <Shawn.Rutledge at qt.io>:
    >
    >>
    >> > On 15 Feb 2017, at 11:11, Marc Mutz <marc.mutz at kdab.com> wrote:
    >> >
    >> > On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote:
    >> >> First of all, apologies for not being able to make the release meeting
    >> >> yesterday. I was in a workshop all day.
    >> >>
    >> >> For the record I think skipping 5.8.1 is a big mistake. I would much
    >> rather
    >> >> delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and
    >> try
    >> >> for a quick 5.9.0.
    >> >
    >> > Amen.
    >> >
    >> > I would like to add that this decision, made behind closed doors, does
    >> not
    >> > match well with Qt-as-an-open-governance-project. In particular, it
    >> feels like
    >> > we OSS contributors are being held hostage here. If you close the 5.8 CI,
    >> > anything we can do, incl. following the dictate of TQC to focus on 5.9,
    >> will
    >> > hurt Qt users one way or another. Either we fragment Qt by releasing a
    >> 5.8.1
    >> > without TQC backing or we leave users hanging in the air for extended
    >> periods
    >> > of time without the ability for bugfixes. Both are unacceptable, IMHO.
    >>
    >> There are a lot of potential bug fixes.  Skipping 5.8.1 might pull some
    >> users into upgrading to 5.9 sooner than they might otherwise, which is good
    >> from one side, but the ones who are afraid of new features and new
    >> regressions will resist.  So I think it’s a mistake because of those
    >> people…
    >>
    >
    > Speaking for myself, I also think, skipping 5.8.1 is a mistake. We just
    > upgraded our project from 5.6 to 5.8 and realized that it had several
    > regressions. For example we are using a QNetworkAccessManager and for
    > random reasons it always switches to NotAccessible after some minutes. No
    > recovery possible except restarting the application. I wonder why nobody
    > else got affected by this. I _think_ the cause was QTBUG-51543, even though
    > I never finally understood whats going on. In any case, the fix for this
    > bug went into 5.8.1, which now won't get released. For me this is very
    > frustrating, since we counted our next milestone on an early 5.8.1 release.
    > Now I would have to wait for 5.9.0 which is planned end of May if
    > everything goes smooth. Even then, there is no guarantee that there is no
    > new regression which would require 5.9.1 release.
    > I also can't produce custom builds, since I never managed to create a
    > custom offline installer for my team members (we are are non profil OSS
    > group without many infrastructure and resources). I do regular builds of Qt
    > itself, but the rest is out of my capabilities.
    >
    > In summary, for me it is very unfortunate that I have to delay our
    > milestone minimum until June if everything goes well.
    
    
    +1
    
    I think, for many quality focused software projects, skipping patch  
    releases in Qt is a pain.
    
    I would even go further: I recommend to establish guidelines how many  
    patch releases should be published (I think at minimum 1, better 2). I  
    would give them absolute priority over new minor (or even major)  
    releases. If there are shortages in CI , CPU or Disk power, whis  
    should primary affeect new releases, not patch releases.
    This would
    a) support Qt not bo become one of the thousand feature rich but  
    unstable and buggy software frameworks/projects
    b) taking pressure on fixing this basic shortages
    
    If I had to decide between new features and bugfixed/mature code - I  
    would go for mature code.
    
    just my 2 cents,
    Torben
    
    
    _______________________________________________
    Releasing mailing list
    Releasing at qt-project.org
    http://lists.qt-project.org/mailman/listinfo/releasing