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

Wed Feb 15 19:55:10 CET 2017

Now I have yo middle post. See after Tuukka

> Sent: Wednesday, February 15, 2017 at 12:13 PM
> From: "Tuukka Turunen" <tuukka.turunen at qt.io>
> To: "Torben Dannhauer" <torben at dannhauer.info>, "releasing at qt-project.org" <releasing at qt-project.org>
> Subject: Re: [Releasing] [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
>
> 
> 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.

I would hope that with COIN and the rest of the build pipeline improvements, we can /eventually/ get to a bi-monthly or monthly patch releases cycle which are more or less "automatic"? (Whatever is fit to release gets automatically released) Though I imagine it's not that simple I think that would be a good goal to have.

> 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
>     
> 
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing
>