Now I have yo middle post. See after Tuukka > Sent: Wednesday, February 15, 2017 at 12:13 PM > From: "Tuukka Turunen" <[email protected]> > To: "Torben Dannhauer" <[email protected]>, "[email protected]" > <[email protected]> > 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" > <[email protected] on behalf of > [email protected]> wrote: > > > Zitat von Roland Winklmeier <[email protected]>: > > > 2017-02-15 12:52 GMT+01:00 Shawn Rutledge <[email protected]>: > > > >> > >> > On 15 Feb 2017, at 11:11, Marc Mutz <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/releasing > > > _______________________________________________ > Releasing mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/releasing > _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
