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

[Tuukka Turunen]

From: Development  on 
behalf of Roland Winklmeier 
Date: Friday, 17 February 2017 at 12.20
To: "development@qt-project.org" 
Subject: Re: [Development] Focusing bug fixes to 5.9 branch and patch releases 
during H1/17

Hi Tuukka,

2017-02-16 17:13 GMT+01:00 Tuukka Turunen 
>:
As multiple people and teams have planned their development according to 
initially agreed feature freeze time of Qt 5.9, it would be very inefficient to 
reopen 5.9 now or postpone getting the release out.

I would use the same argument for all customers and users of Qt who planned 
their development on a 5.8.1 release, but with my argument that a bug fix 
release should have priority over a new feature release.


If we can get KDAB and others helping with Qt 5.9 with even remotely similar 
effort than it would be to create Qt 5.8.1 release I am sure we can make an 
awesome Qt 5.9.0 ahead of the planned schedule. This means we can make the CI 
system improvements earlier and thus also have Qt 5.9.1 earlier.

My question might sound sarcastic but it is really serious: Who does guarantee 
me that a 5.9.1 release won't be dropped again in favor of the 5.10 release 
schedule? Maybe I'm not familiar with the process and details how and when a 
decision for a patch release is made, but I learned from this discussions that 
it was expected by most people. If there is no guarantee in the future, this 
decreases dramatically my will to test and fix bugs after a .0 release in this 
branch. My contribution might not be high and in total insignificant though.
This is a valid concern. I can assure you that The Qt Company has nothing 
against patch releases. You can look back in history and see that we do make 
patch releases, sometimes quite many of them. But lately it has become harder 
and harder. Now we want to fix the fundamentals and get back to normal mode of 
operations with Qt 5.9, including making patch releases.
Yours,
Tuukka

I can only repeat my personal opinion: Bug fixes first, then new features. If 
the time between two feature releases is too close, then increase the time or 
change to a release-when-its-ready timeline.
My 2 cts.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMacCocoaViewContainer changes?

[René J . V . Bertin]

On Friday February 17 2017 13:55:34 Timur Pocheptsov wrote:
> Do you have a smaller reproducer for this? Something not as big as designer 
> or vlc?

Sorry, no. Not yet at least. First thing I tried was releasing the native view 
in the QMacCocoaViewContainer example, but that doesn't cause a crash.

I suspect that this is due to Designer's list of available widgets in the 
Widget Box causing it to call the QMacCocoaViewContainer dtor during startup.


R.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMacCocoaViewContainer changes?

[Timur Pocheptsov]

Do you have a smaller reproducer for this? Something not as big as designer or 
vlc?


Best regards,

Timur.


From: René J.V. Bertin 
Sent: Friday, February 17, 2017 2:52:27 PM
To: Timur Pocheptsov
Cc: development@qt-project.org; sit...@kde.org
Subject: Re: [Development] QMacCocoaViewContainer changes?

Here you go:
https://bugreports.qt.io/browse/QTBUG-59001

R.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Decrease amounth of delivered src packages

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 15 de febrero de 2017 17:29:43 ART Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2017 15:11:49 PST Mathias Hasselmann
> 
> wrote:
> > That's a somewhat limited point of view. Yes, xz archives are slightly
> > smaller, but to be honest: In the days of 4K video streaming saving
> > 100MiB of download size doesn't seem as important as it was.
> 
> There are still people with bad or slow connections.

And lots of bandwith usage: download from qt, upload to distro server, push to 
every mirror around, users downloading the source code from distros...

Granted, some of we distro maintainers could repack the source code, but it is 
always better to have the original whenever possible.

> > Is it worth to spend 10 additional minutes per CI cycle just to save our
> > users a very few seconds of download time?
> 
> Wait, CI cycle?
> 
> I thought we were talking about releases only, which are final as well as
> snapshot packages. Why is the CI creating tarballs?


If the problem is the CI then the CI might use gz and use xz for released 
tarballs.

-- 
 AlfaScorpii: podés converncerla a tu vieja que le esconda
el diccionario a el_machi? Cada vez que aprende una palabra nueva
busca cualquier excusa para usarla
 e-squizo: leí mi primer diccionario a los 5 años
[...]
 e-squizo: como mi vieja no aprenda lo suficiente de
hacking no veo como haria para bajar el sitio de la real academia
  Visto en #grulic, irc.freenode.net

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Roland Winklmeier]

Hi Tuukka,

2017-02-16 17:13 GMT+01:00 Tuukka Turunen :

> As multiple people and teams have planned their development according to
> initially agreed feature freeze time of Qt 5.9, it would be very
> inefficient to reopen 5.9 now or postpone getting the release out.
>

I would use the same argument for all customers and users of Qt who planned
their development on a 5.8.1 release, but with my argument that a bug fix
release should have priority over a new feature release.


>
> If we can get KDAB and others helping with Qt 5.9 with even remotely
> similar effort than it would be to create Qt 5.8.1 release I am sure we can
> make an awesome Qt 5.9.0 ahead of the planned schedule. This means we can
> make the CI system improvements earlier and thus also have Qt 5.9.1 earlier.
>

My question might sound sarcastic but it is really serious: Who does
guarantee me that a 5.9.1 release won't be dropped again in favor of the
5.10 release schedule? Maybe I'm not familiar with the process and details
how and when a decision for a patch release is made, but I learned from
this discussions that it was expected by most people. If there is no
guarantee in the future, this decreases dramatically my will to test and
fix bugs after a .0 release in this branch. My contribution might not be
high and in total insignificant though.

I can only repeat my personal opinion: Bug fixes first, then new features.
If the time between two feature releases is too close, then increase the
time or change to a release-when-its-ready timeline.

My 2 cts.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Sean Harmer]

On Friday 17 February 2017 08:10:55 Alex Blasche wrote:
> > [...]
> > 
> > I note that an answer on this is still pending, but as an aside: CI on
> > 5.8 (and 5.6) appears to be smooth sailing the last two days. Hardly any
> > false failures anymore.
> 
> The CI integration process is only partly to blame. Yes, after each fix
> round there is a new round of qt5 git integrations with more unit test
> fixes followed by a new round of package generation.
> > I do realise that the main load probably comes from qt5.git
> > integrations, but even so, if 5.8 (qtbase) integrations run through the
> > first time instead of requiring half a dozen restages, either the CI
> > load is lowered significantly, helping to avoid flakiness in other
> > tests, or allowing more stuff to be merged per unit time.
> 
> Each of the packages must be tested. We are talking about 17 different types
> of packages. For each package the tester has to install the package and run
> a series of tests. This means you have to have testers for each platform
> and this takes half a day to do.  We are talking about principle testing
> for each feature domain, QtCreator, app install & deployment, completeness
> of the install package etc. it is not a sexy task either as it is very
> mundane.

Some steps of this can be automated with squish or similar but I appreciate 
that may not be the case at the current time.

> This also assumes that each tester has time to do the testing at the same
> time. Whenever the last platform tester finishes that's when you can
> progress to the next step.

And this is one of the areas which KDAB is offering to help with if it gets a 
5.8.1 release out. But we can only do this if the candidate packages are made 
available.

> 5.8.1 is a release with a lot of changes. It would not be a low effort
> release testing. I do not believe that smoke testing is sufficient. At
> least the past .1 have very much proven this fact.

Sure, but 5.9.0 has even more changes and is therefore more of a risk of 
taking longer. Nobody is debating that making a .1 release is not a lot of 
effort. What we are arguing is that making 5.8.1 is more important than 
releasing 5.9.0 a few weeks earlier than if there is a 5.8.1.

As makers of a toolkit there is an implicit promise that there will be timely 
bug fix releases. It seems that The Qt Company has decided otherwise and that 
releasing 5.9.0 before the summer vacations is more important.

At the end of the day, all we, KDAB and other community members, can do is 
point out that your customers may well not see it this way and offer to help. 
But since you control all of the infrastructure there is little else we can do 
about it.

> Yes, there is things we can and want to improve but we are not there yet. I
> also do not believe that making a bad release is helping customers either.

Again, nobody wants a bad release. We're suggesting a different prioritisation 
of releases, not sacrificing on quality for any of them.

Cheers,

Sean

> > Shutting down 5.8 because of load problems in the CI now makes even less
> > sense than before.
> 
> As shown above it is not.
> --
> Alex
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMacCocoaViewContainer changes?

[Timur Pocheptsov]

Yes, please, provide all the related details in the report.


Best regards,

Timur.


From: René J.V. Bertin 
Sent: Friday, February 17, 2017 10:09:14 AM
To: Timur Pocheptsov
Cc: development@qt-project.org
Subject: Re: [Development] QMacCocoaViewContainer changes?

On Friday February 17 2017 08:41:13 Timur Pocheptsov wrote:

>qnsview_cast is using Obj-C RTTI. An object with a type inheriting QNSView 
>will pass isKindOfClass:[QNSView class] test.

Doh, yes, of course. In that case the message is probably appropriate though 
still a bit counterproductive if given fo a QMacCocoaViewContainer's view.
Should I report that too?

R.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMacCocoaViewContainer changes?

[René J . V . Bertin]

On Friday February 17 2017 08:41:13 Timur Pocheptsov wrote:

>qnsview_cast is using Obj-C RTTI. An object with a type inheriting QNSView 
>will pass isKindOfClass:[QNSView class] test.

Doh, yes, of course. In that case the message is probably appropriate though 
still a bit counterproductive if given fo a QMacCocoaViewContainer's view.
Should I report that too?

R.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMacCocoaViewContainer changes?

[Timur Pocheptsov]

Ok, don't hesitate to report it.

qnsview_cast is using Obj-C RTTI. An object with a type inheriting QNSView will 
pass isKindOfClass:[QNSView class] test.



Best regards,

 Timur.


From: René J.V. Bertin 
Sent: Friday, February 17, 2017 9:32:02 AM
To: Timur Pocheptsov
Cc: development@qt-project.org; Harald Sitter
Subject: Re: [Development] QMacCocoaViewContainer changes?

On Friday February 17 2017 05:39:44 Timur Pocheptsov wrote:

Hello Timur,

I was planning to, but after I gather some more observations, to get an idea if 
indeed the foreign NSView gets released before calling the 
QMacCocoaViewContainer dtor, and where. I also want to try to get some 
certainty that we're not talking simply talking about a regression in Qt 
Designer.

What is definitely new in 5.8 is qnsview_cast(), which I think warns a bit too 
enthusiastically about casting something not a QNSView*. It's not related to 
this crash, but shouldn't it at least accept instances of classes that inherit 
QNSView*? A simple cast won't fool the ObjC runtime anyway.

R.

>Hello,
>
>
>could you, please, create a JIRA ticket for this (if not done yet)?
>
>I remember some changes - but it was 5.6, so 5.7.1 would be also broken then 
>...
>
>
>Best regards,
>
>Timur.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMacCocoaViewContainer changes?

[René J . V . Bertin]

On Friday February 17 2017 05:39:44 Timur Pocheptsov wrote:

Hello Timur,

I was planning to, but after I gather some more observations, to get an idea if 
indeed the foreign NSView gets released before calling the 
QMacCocoaViewContainer dtor, and where. I also want to try to get some 
certainty that we're not talking simply talking about a regression in Qt 
Designer.

What is definitely new in 5.8 is qnsview_cast(), which I think warns a bit too 
enthusiastically about casting something not a QNSView*. It's not related to 
this crash, but shouldn't it at least accept instances of classes that inherit 
QNSView*? A simple cast won't fool the ObjC runtime anyway.

R.

>Hello,
>
>
>could you, please, create a JIRA ticket for this (if not done yet)?
>
>I remember some changes - but it was 5.6, so 5.7.1 would be also broken then 
>...
>
>
>Best regards,
>
>Timur.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMacCocoaViewContainer changes?

[Philippe]

I observed some change too. In my case, a NSView, created on the client
side ("my side"), and inserted inside a Qt hierarchy, is now released
automatically by Qt.
Before, I had to release this NSView "manually". When switching to Qt
5.8, the NSView was released twice (client + Qt sides), causing a crash
in OSX code.

Simply not releasing the NSView on the client side, is enough
(apparently so far), to solve the problem.

I did not report a bug, because this looks more like a behavior change 
(not documented), than a bug.

Philippe

On Thu, 16 Feb 2017 23:21:52 +0100
René J.V. Bertin  wrote:

> Hello,
> 
> Has anything changed in Qt 5.8.0 with the way the QMacCocoaViewContainer 
> class has to be used? I observe the following after updating from 5.7.1 to 
> 5.8.0 :
> 
> - Qt Designer crashes when I have Phonon 4.9.x installed with the 
> phonon-backend-vlc git/master backend (https://cgit.kde.org/phonon-vlc.git/). 
> - the QMacCocoaViewContainer ctor now also calls 
> QMacCocoaViewContainer::setCocoaView() when a NULL NSView pointer is given.
> - the QMacCocoaViewContainer example no longer releases the native view after 
> passing it to setCocoaView(), despite what the documentation says, and 
> despite the fact that setCocoaView indeed does a retain. Not releasing the 
> VideoView instance in phonon-vlc's VlcMacWidget ctor also prevents the 
> Designer crash but theoretically means the instance is being leaked.
> 
> The Designer crash is preceded by the terminal output below and occurs in 
> ~QMacCocoaViewContainer(), when doing [nsview release]. This means it's doing 
> one release too many, as confirmed by the malloc error.
> qt.qpa.cocoa.window: NSView is not QNSView, consider checking for 
> Qt::ForeignWindow
> qt.qpa.cocoa.window: NSView is not QNSView, consider checking for 
> Qt::ForeignWindow
> Designer(97879,0x7fff721fd310) malloc: *** error for object 0x7fc7cf2a3300: 
> pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> 
> 
> Thanks,
> R.
> ___
> 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

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

[Alex Blasche]

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Marc Mutz

> > Also, to allow others to help with the release process, could you
> > explain where the main bottle neck is with the release process please?
> > Is it the package generation itself? The smoke testing? Something
> > else?
> [...]
> 
> I note that an answer on this is still pending, but as an aside: CI on
> 5.8 (and 5.6) appears to be smooth sailing the last two days. Hardly any
> false failures anymore.

The CI integration process is only partly to blame. Yes, after each fix round 
there is a new round of qt5 git integrations with more unit test fixes followed 
by a new round of package generation.

 
> I do realise that the main load probably comes from qt5.git
> integrations, but even so, if 5.8 (qtbase) integrations run through the
> first time instead of requiring half a dozen restages, either the CI
> load is lowered significantly, helping to avoid flakiness in other
> tests, or allowing more stuff to be merged per unit time.

Each of the packages must be tested. We are talking about 17 different types of 
packages. For each package the tester has to install the package and run a 
series of tests. This means you have to have testers for each platform and this 
takes half a day to do.  We are talking about principle testing for each 
feature domain, QtCreator, app install & deployment, completeness of the 
install package etc. it is not a sexy task either as it is very mundane.

This also assumes that each tester has time to do the testing at the same time. 
Whenever the last platform tester finishes that's when you can progress to the 
next step.

5.8.1 is a release with a lot of changes. It would not be a low effort release 
testing. I do not believe that smoke testing is sufficient. At least the past 
.1 have very much proven this fact.

Yes, there is things we can and want to improve but we are not there yet. I 
also do not believe that making a bad release is helping customers either.

> Shutting down 5.8 because of load problems in the CI now makes even less
> sense than before.

As shown above it is not.
--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development