Re: [Development] QTestLib: sending mouse move and release events outside windows

[Mitch Curtis]

Ahhh, right. Well, I hope someone who knows this code well can chime in.

From: Gatis Paeglis
Sent: Monday, 16 April 2018 5:39 PM
To: Mitch Curtis ; development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows


> I think that maybe we’re talking about different things, because the 
> functionality works for me (both in the app and testlib), I just want to 
> disable the warnings. :)



Its all related :)



> QTest::mouseMove(, QPoint(600, 600));



It is not clear to me what is the expected to happen after this call:



a) Documentation in incomplete.

b) Warning is not critical (it does not return from the function).

c) Looking at the source code this calls ends up doing nothing.



So I was wondering if there is a bigger issue and hiding a warning might not be 
the right solution. But if it works, it works.


From: Mitch Curtis
Sent: Monday, April 16, 2018 5:28:07 PM
To: Gatis Paeglis; development@qt-project.org
Subject: RE: QTestLib: sending mouse move and release events outside windows


I think that maybe we’re talking about different things, because the 
functionality works for me (both in the app and testlib), I just want to 
disable the warnings. :)



From: Gatis Paeglis
Sent: Monday, 16 April 2018 5:08 PM
To: Mitch Curtis >; 
development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows



> I was thinking of something that would be public API, as any user who wants 
> to tests drags that end up outside a window will run into the same issue.



That kind of API I think requires serious redesign in qtestlib. If you want to 
drag outside a window and then back to test Enter/Leave events (system 
generated, not the synthetic ones for alien widgets), then we have to use 
system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking 
events. Both modes are useful, mocked vs system events, but that is another 
story.



If you want to move outside a window and keep on receiving all mouse events, 
then you need to grab the mouse/pointer. That is different API from the above 
Enter/Leave scenario. QTestLib currently does not support any of the above.





From: Mitch Curtis
Sent: Monday, April 16, 2018 1:14:23 PM
To: Gatis Paeglis; development@qt-project.org
Subject: RE: QTestLib: sending mouse move and release events outside windows



> That warning message was added by [1]. I have never fully understood the 
> motivation for that warning. The documentation from [2] does not say if 
> global coordinates are allowed.



I suppose it could be useful if you didn’t intend to send events outside of the 
window.



> QTest sends all mouse events down to QWindowSystemInterface, which does 
> expect a window as an argument, or nullptr on window-less systems (eglfs). So 
> if you want to simulate a mouse move/press/release outside a window you could 
> try to use that code path...



I was thinking of something that would be public API, as any user who wants to 
tests drags that end up outside a window will run into the same issue.



What do you think about a flag that can be set for the duration of a function 
(i.e. automatically reset at the end of that function)? 
setWarnOnEventsOutsideWindow?



Or, to involve the discussion about failing on warnings, we could add a more 
generic flag getter/setter. We already have [1] a bunch of currentTestFunction 
functions:



const char *currentAppName()

const char *currentDataTag()

bool currentTestFailed()

const char *currentTestFunction()



So, perhaps we could add 
currentTestFunctionFlags()/setCurrentTestFunctionFlags().



TestFunctionFlag {

WarnOnEventsOutsideWindow = 0x01, // enabled by default

FailOnWarnings = 0x02 // disabled by default

};



[1] http://doc.qt.io/qt-5/qtest.html#keyClicks



From: Gatis Paeglis
Sent: Monday, 16 April 2018 12:29 PM
To: Mitch Curtis >; 
development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows



That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT  see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?



[1] https://codereview.qt-project.org/#/c/53474/

[2] 

Re: [Development] QTestLib: sending mouse move and release events outside windows

[Gatis Paeglis]

> I think that maybe we’re talking about different things, because the 
> functionality works for me (both in the app and testlib), I just want to 
> disable the warnings. :)


Its all related :)


> QTest::mouseMove(, QPoint(600, 600));


It is not clear to me what is the expected to happen after this call:


a) Documentation in incomplete.

b) Warning is not critical (it does not return from the function).

c) Looking at the source code this calls ends up doing nothing.


So I was wondering if there is a bigger issue and hiding a warning might not be 
the right solution. But if it works, it works.


From: Mitch Curtis
Sent: Monday, April 16, 2018 5:28:07 PM
To: Gatis Paeglis; development@qt-project.org
Subject: RE: QTestLib: sending mouse move and release events outside windows


I think that maybe we’re talking about different things, because the 
functionality works for me (both in the app and testlib), I just want to 
disable the warnings. :)



From: Gatis Paeglis
Sent: Monday, 16 April 2018 5:08 PM
To: Mitch Curtis ; development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows



> I was thinking of something that would be public API, as any user who wants 
> to tests drags that end up outside a window will run into the same issue.



That kind of API I think requires serious redesign in qtestlib. If you want to 
drag outside a window and then back to test Enter/Leave events (system 
generated, not the synthetic ones for alien widgets), then we have to use 
system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking 
events. Both modes are useful, mocked vs system events, but that is another 
story.



If you want to move outside a window and keep on receiving all mouse events, 
then you need to grab the mouse/pointer. That is different API from the above 
Enter/Leave scenario. QTestLib currently does not support any of the above.





From: Mitch Curtis
Sent: Monday, April 16, 2018 1:14:23 PM
To: Gatis Paeglis; development@qt-project.org
Subject: RE: QTestLib: sending mouse move and release events outside windows



> That warning message was added by [1]. I have never fully understood the 
> motivation for that warning. The documentation from [2] does not say if 
> global coordinates are allowed.



I suppose it could be useful if you didn’t intend to send events outside of the 
window.



> QTest sends all mouse events down to QWindowSystemInterface, which does 
> expect a window as an argument, or nullptr on window-less systems (eglfs). So 
> if you want to simulate a mouse move/press/release outside a window you could 
> try to use that code path...



I was thinking of something that would be public API, as any user who wants to 
tests drags that end up outside a window will run into the same issue.



What do you think about a flag that can be set for the duration of a function 
(i.e. automatically reset at the end of that function)? 
setWarnOnEventsOutsideWindow?



Or, to involve the discussion about failing on warnings, we could add a more 
generic flag getter/setter. We already have [1] a bunch of currentTestFunction 
functions:



const char *currentAppName()

const char *currentDataTag()

bool currentTestFailed()

const char *currentTestFunction()



So, perhaps we could add 
currentTestFunctionFlags()/setCurrentTestFunctionFlags().



TestFunctionFlag {

WarnOnEventsOutsideWindow = 0x01, // enabled by default

FailOnWarnings = 0x02 // disabled by default

};



[1] http://doc.qt.io/qt-5/qtest.html#keyClicks



From: Gatis Paeglis
Sent: Monday, 16 April 2018 12:29 PM
To: Mitch Curtis >; 
development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows



That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT ?? see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?



[1] https://codereview.qt-project.org/#/c/53474/

[2] http://doc.qt.io/qt-5/qtest.html#mouseMove

[3] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021



From: Development 
>
 on behalf of Mitch Curtis 

Re: [Development] QTestLib: sending mouse move and release events outside windows

[Mitch Curtis]

I think that maybe we’re talking about different things, because the 
functionality works for me (both in the app and testlib), I just want to 
disable the warnings. :)

From: Gatis Paeglis
Sent: Monday, 16 April 2018 5:08 PM
To: Mitch Curtis ; development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows


> I was thinking of something that would be public API, as any user who wants 
> to tests drags that end up outside a window will run into the same issue.



That kind of API I think requires serious redesign in qtestlib. If you want to 
drag outside a window and then back to test Enter/Leave events (system 
generated, not the synthetic ones for alien widgets), then we have to use 
system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking 
events. Both modes are useful, mocked vs system events, but that is another 
story.



If you want to move outside a window and keep on receiving all mouse events, 
then you need to grab the mouse/pointer. That is different API from the above 
Enter/Leave scenario. QTestLib currently does not support any of the above.




From: Mitch Curtis
Sent: Monday, April 16, 2018 1:14:23 PM
To: Gatis Paeglis; development@qt-project.org
Subject: RE: QTestLib: sending mouse move and release events outside windows


> That warning message was added by [1]. I have never fully understood the 
> motivation for that warning. The documentation from [2] does not say if 
> global coordinates are allowed.



I suppose it could be useful if you didn’t intend to send events outside of the 
window.



> QTest sends all mouse events down to QWindowSystemInterface, which does 
> expect a window as an argument, or nullptr on window-less systems (eglfs). So 
> if you want to simulate a mouse move/press/release outside a window you could 
> try to use that code path...



I was thinking of something that would be public API, as any user who wants to 
tests drags that end up outside a window will run into the same issue.



What do you think about a flag that can be set for the duration of a function 
(i.e. automatically reset at the end of that function)? 
setWarnOnEventsOutsideWindow?



Or, to involve the discussion about failing on warnings, we could add a more 
generic flag getter/setter. We already have [1] a bunch of currentTestFunction 
functions:



const char *currentAppName()

const char *currentDataTag()

bool currentTestFailed()

const char *currentTestFunction()



So, perhaps we could add 
currentTestFunctionFlags()/setCurrentTestFunctionFlags().



TestFunctionFlag {

WarnOnEventsOutsideWindow = 0x01, // enabled by default

FailOnWarnings = 0x02 // disabled by default

};



[1] http://doc.qt.io/qt-5/qtest.html#keyClicks



From: Gatis Paeglis
Sent: Monday, 16 April 2018 12:29 PM
To: Mitch Curtis >; 
development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows



That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT  see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?



[1] https://codereview.qt-project.org/#/c/53474/

[2] http://doc.qt.io/qt-5/qtest.html#mouseMove

[3] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021



From: Development 
>
 on behalf of Mitch Curtis >
Sent: Monday, April 16, 2018 11:56:56 AM
To: development@qt-project.org
Subject: [Development] QTestLib: sending mouse move and release events outside 
windows



https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move 
and release events outside of a window causes warnings:

void Test::test_case1()
{
QWindow window;
window.resize(400, 400);

// Start inside and drag outside (e.g. moving a selection to the edge of a
// canvas should scroll the canvas).
QTest::mousePress(, Qt::LeftButton, Qt::NoModifier, QPoint(200, 
200));

const QRegularExpression regex(".*Mouse event at .* occurs outside of 
target window.*");
QVERIFY(regex.isValid());

const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 
occurs outside of 

[Development] Coin maintenance notification

[Aapo Keskimölö]

Coin production has been updated with a new baseline today.

These are the most fundamental improvements:
- Coin now supports common folder split (for instance, changing Linux common 
scripts no longer causes reprovisioning Mac and Windows machines, etc)
- Performance improvements in creation of workitems should make scheduling of 
qt5 integration faster
- Better asynchronous task scheduling of scheduler and storage operations
- Lots of small bug fixes 

The applied amount of patches was 171 in total, thus we do not expect this to 
go out without experiencing some problems. 

In case you are not able to merge changes and you think CI is causing the 
issue, you may give drop by at #qtci or if you are an external user, you may 
create a JIRA ticket https://wiki.qt.io/Reporting_Bugs#Reporting_bugs_for_Coin

Kind regards/Ystävällisin terveisin,
Aapo Keskimölö


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

Re: [Development] QTestLib: sending mouse move and release events outside windows

[Gatis Paeglis]

> I was thinking of something that would be public API, as any user who wants 
> to tests drags that end up outside a window will run into the same issue.


That kind of API I think requires serious redesign in qtestlib. If you want to 
drag outside a window and then back to test Enter/Leave events (system 
generated, not the synthetic ones for alien widgets), then we have to use 
system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking 
events. Both modes are useful, mocked vs system events, but that is another 
story.


If you want to move outside a window and keep on receiving all mouse events, 
then you need to grab the mouse/pointer. That is different API from the above 
Enter/Leave scenario. QTestLib currently does not support any of the above.



From: Mitch Curtis
Sent: Monday, April 16, 2018 1:14:23 PM
To: Gatis Paeglis; development@qt-project.org
Subject: RE: QTestLib: sending mouse move and release events outside windows


> That warning message was added by [1]. I have never fully understood the 
> motivation for that warning. The documentation from [2] does not say if 
> global coordinates are allowed.



I suppose it could be useful if you didn’t intend to send events outside of the 
window.



> QTest sends all mouse events down to QWindowSystemInterface, which does 
> expect a window as an argument, or nullptr on window-less systems (eglfs). So 
> if you want to simulate a mouse move/press/release outside a window you could 
> try to use that code path...



I was thinking of something that would be public API, as any user who wants to 
tests drags that end up outside a window will run into the same issue.



What do you think about a flag that can be set for the duration of a function 
(i.e. automatically reset at the end of that function)? 
setWarnOnEventsOutsideWindow?



Or, to involve the discussion about failing on warnings, we could add a more 
generic flag getter/setter. We already have [1] a bunch of currentTestFunction 
functions:



const char *currentAppName()

const char *currentDataTag()

bool currentTestFailed()

const char *currentTestFunction()



So, perhaps we could add 
currentTestFunctionFlags()/setCurrentTestFunctionFlags().



TestFunctionFlag {

WarnOnEventsOutsideWindow = 0x01, // enabled by default

FailOnWarnings = 0x02 // disabled by default

};



[1] http://doc.qt.io/qt-5/qtest.html#keyClicks



From: Gatis Paeglis
Sent: Monday, 16 April 2018 12:29 PM
To: Mitch Curtis ; development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows



That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT ?? see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?



[1] https://codereview.qt-project.org/#/c/53474/

[2] http://doc.qt.io/qt-5/qtest.html#mouseMove

[3] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021



From: Development 
>
 on behalf of Mitch Curtis >
Sent: Monday, April 16, 2018 11:56:56 AM
To: development@qt-project.org
Subject: [Development] QTestLib: sending mouse move and release events outside 
windows



https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move 
and release events outside of a window causes warnings:

void Test::test_case1()
{
QWindow window;
window.resize(400, 400);

// Start inside and drag outside (e.g. moving a selection to the edge of a
// canvas should scroll the canvas).
QTest::mousePress(, Qt::LeftButton, Qt::NoModifier, QPoint(200, 
200));

const QRegularExpression regex(".*Mouse event at .* occurs outside of 
target window.*");
QVERIFY(regex.isValid());

const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 
occurs outside of target window (400x400)."));
QVERIFY(match.hasMatch());

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseMove(, QPoint(600, 600));

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseRelease(, Qt::LeftButton, Qt::NoModifier, QPoint(600, 
600));
}

Output:

* Start testing of Test *
Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 
shared (dynamic) debug build; by MSVC 2017)
PASS   : 

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Alex Blasche]

> -Original Message-
> From: Development [mailto:development-
> Keeping release tags is OK for me. Motivation behind my proposal was to stop
> planning other release dates than FF & final target. Currently we are trying 
> to
> estimate also alpha, beta and RC release dates and it seems to cause some
> delays for us: persons aren't fixing blocker issues or doing the test because 
> it
> seems there is a time to do that later (because e.g RC date is planned to be 
> after
> a month). So if the way to go is to do these "releases" immediately when ready
> it might help us to get fixes in earlier and so on also get releases out 
> quicker...

At large I agree with Frederik. The bug side of thing (which delays) we could 
handle in a flexible manor exactly as described by Frederik. I do like to 
emphasize though that the dates for first beta and first RC are important (and 
FF is alpha) because they define times when certain level of changes are no 
longer permitted (e.g. after first beta no API changes). Therefore, you will 
not get around setting a target date for first Beta and RC.

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

Re: [Development] qdds image format

[Giuseppe D'Angelo]

On 16/04/18 12:23, Иван Комиссаров wrote:

So, how those issues are checked? Any tool or what?


Looking at the email archives: it was fuzzed through AFL. I don't have 
the test images still around, but in my experience a simple multi-image 
file was enough to trigger a crash. (I used to see this in Creator, when 
accidentally opening a DDS in its builtin image preview).


But again, why having such an image loader in Qt? It's not going to be 
useful in 99.9% of the use cases where you use a DDS file.


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Frederik Gladhorn]

On mandag 16. april 2018 11.35.28 CEST Jani Heikkinen wrote:
> Hi!
> 
> Keeping release tags is OK for me. Motivation behind my proposal was to stop
> planning other release dates than FF & final target. Currently we are
> trying to estimate also alpha, beta and RC release dates and it seems to
> cause some delays for us: persons aren't fixing blocker issues or doing the
> test because it seems there is a time to do that later (because e.g RC date
> is planned to be after a month). So if the way to go is to do these
> "releases" immediately when ready it might help us to get fixes in earlier
> and so on also get releases out quicker...

This sounds like it is the real issue. In my opinion, we should have a list of 
"known issues for betas" (does anyone know of a good way of tracking these, so 
that it's obvious and little work?). JIRA? Somewhere else?

I think each beta is for finding more issues (if we consider it necessary), but 
we should not have anything block a beta from going out (OK, maybe if it 
doesn't compile, but how did we end up in such a bad state?). So there is the 
beta with a potentially growing and then shrinking list of release blockers.

This means we may have critical bugs not fixed in the next beta, only in the RC 
latest.
At the same time, I do wonder how strong the argument for more than one beta 
release really is. We should rather offer continuous post-beta snapshots, but 
IMHO we should only ask to test exactly once, during one beta.
If we then trust that we fix the issues that were uncovered, we should move to 
the RC phase, without another beta (beta2/3/4/... contain very few changes 
compared to the first one anyway). There is little value in asking a great 
amount of people to re-test. The bad issues uncovered in the beta can be 
tested using post-beta snapshots, as needed.

The only thing that can be blocked imho is the release candidate. We should 
never have a release candidate that does not include fixes for all known 
issues. The release candidate should then turn into the final release after a 
brief sanity check. There must not be any changes from release candidate to 
release. If it turns out that we really messed up badly, we'll have another RC 
+ release.

I think this would help us get releases out quickly. It would mean, we really 
need to play by our own rules:
after alpha: no more API changes, unless fixing new API. All new features must 
be _complete_, with no known big bugs (or thrown out again). I am certainly 
guilty of breaking this rule in the past and delaying releases...
after beta: no more changes, except for fixes for release blockers
release candidate: no more changes, unless brown paper bag issues are found

Cheers,
Frederik



> 
> But this change doesn't meant we need to stop calling those releases as
> Alpha or Betas so we can continue labeling those as earlier.
> 
> br,
> Jani
> 
> > -Original Message-
> > From: Development  > project.org> On Behalf Of Lars Knoll
> > Sent: maanantai 16. huhtikuuta 2018 10.03
> > To: Simon Hausmann 
> > Cc: Qt development mailing list 
> > Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for
> > release
> > process change
> > 
> > Hi,
> > 
> > From a releasing perspective I agree that the set we should update our
> > packages often. We should also stop delivering source only alpha packages,
> > and have binaries from the get go.
> > 
> > But from a user perspective, I agree that it's good and important to put a
> > name to those releases so people know what to expect from them.
> > Snapshots as long as the packages are created from the dev branch, then
> > alpha, beta, RC and final. We could discuss whether we need the alpha
> > label, or whether we can go directly to beta, but I believe that we do
> > need the other tags.
> > 
> > But I do agree with releasing packages as often as possible, and we should
> > have them already before FF from the dev branch (if possible).
> > 
> > So I’d propose to have our packages updated often. But we do keep the
> > ‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags.
> > 
> > - Snapshot packages from the dev branch
> > - FF and branching occur together and packages are getting the ‘alpha’ tag
> > - Agree that we should start with the API review immediately.
> > - Beta once API review is done
> > - RC once we have the release branch and all currently known blockers are
> > fixed
> > 
> > That should be pretty close to what Jani described, only that we keep the
> > tags for our users.
> > 
> > Cheers,
> > Lars
> > 
> > > On 16 Apr 2018, at 08:43, Simon Hausmann 
> > 
> > wrote:
> > > Hi,
> > > 
> > > Same here. At first this seemed like a good idea, but it becomes awkward
> > 
> > when you look at it from the dev workflow point of view: After fixing a
> > bug, what is the fix version? Reported in snapshot-24062918 and fixed in
> > 

Re: [Development] QTestLib: sending mouse move and release events outside windows

[Mitch Curtis]

> That warning message was added by [1]. I have never fully understood the 
> motivation for that warning. The documentation from [2] does not say if 
> global coordinates are allowed.

I suppose it could be useful if you didn’t intend to send events outside of the 
window.

> QTest sends all mouse events down to QWindowSystemInterface, which does 
> expect a window as an argument, or nullptr on window-less systems (eglfs). So 
> if you want to simulate a mouse move/press/release outside a window you could 
> try to use that code path...

I was thinking of something that would be public API, as any user who wants to 
tests drags that end up outside a window will run into the same issue.

What do you think about a flag that can be set for the duration of a function 
(i.e. automatically reset at the end of that function)? 
setWarnOnEventsOutsideWindow?

Or, to involve the discussion about failing on warnings, we could add a more 
generic flag getter/setter. We already have [1] a bunch of currentTestFunction 
functions:

const char *currentAppName()
const char *currentDataTag()
bool currentTestFailed()
const char *currentTestFunction()

So, perhaps we could add 
currentTestFunctionFlags()/setCurrentTestFunctionFlags().

TestFunctionFlag {
WarnOnEventsOutsideWindow = 0x01, // enabled by default
FailOnWarnings = 0x02 // disabled by default
};

[1] http://doc.qt.io/qt-5/qtest.html#keyClicks

From: Gatis Paeglis
Sent: Monday, 16 April 2018 12:29 PM
To: Mitch Curtis ; development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows


That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT  see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?



[1] https://codereview.qt-project.org/#/c/53474/

[2] http://doc.qt.io/qt-5/qtest.html#mouseMove

[3] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021


From: Development 
>
 on behalf of Mitch Curtis >
Sent: Monday, April 16, 2018 11:56:56 AM
To: development@qt-project.org
Subject: [Development] QTestLib: sending mouse move and release events outside 
windows

https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move 
and release events outside of a window causes warnings:

void Test::test_case1()
{
QWindow window;
window.resize(400, 400);

// Start inside and drag outside (e.g. moving a selection to the edge of a
// canvas should scroll the canvas).
QTest::mousePress(, Qt::LeftButton, Qt::NoModifier, QPoint(200, 
200));

const QRegularExpression regex(".*Mouse event at .* occurs outside of 
target window.*");
QVERIFY(regex.isValid());

const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 
occurs outside of target window (400x400)."));
QVERIFY(match.hasMatch());

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseMove(, QPoint(600, 600));

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseRelease(, Qt::LeftButton, Qt::NoModifier, QPoint(600, 
600));
}

Output:

* Start testing of Test *
Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 
shared (dynamic) debug build; by MSVC 2017)
PASS   : Test::initTestCase()
WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target 
window (400x400).
WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target 
window (400x400).
INFO   : Test::test_case1() Did not receive any message matching: ".*Mouse 
event at .* occurs outside of target window.*"
INFO   : Test::test_case1() Did not receive any message matching: ".*Mouse 
event at .* occurs outside of target window.*"
FAIL!  : Test::test_case1() Not all expected messages were received
PASS   : Test::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms
* Finished testing of Test *

Mouse move and release events occurring outside of a window is not uncommon, so 
there should be a way to disable these warnings.

Using QTest::ignoreWarning() has no effect here, because the message logger 
system is (probably intentionally) bypassed.

Does anyone know why this is the case?

Also, does anyone have any ideas about how to solve this?

One suggestion was 

Re: [Development] QTestLib: sending mouse move and release events outside windows

[Gatis Paeglis]

That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT  see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?


[1] https://codereview.qt-project.org/#/c/53474/

[2] http://doc.qt.io/qt-5/qtest.html#mouseMove

[3] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021


From: Development  on 
behalf of Mitch Curtis 
Sent: Monday, April 16, 2018 11:56:56 AM
To: development@qt-project.org
Subject: [Development] QTestLib: sending mouse move and release events outside 
windows

https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move 
and release events outside of a window causes warnings:

void Test::test_case1()
{
QWindow window;
window.resize(400, 400);

// Start inside and drag outside (e.g. moving a selection to the edge of a
// canvas should scroll the canvas).
QTest::mousePress(, Qt::LeftButton, Qt::NoModifier, QPoint(200, 
200));

const QRegularExpression regex(".*Mouse event at .* occurs outside of 
target window.*");
QVERIFY(regex.isValid());

const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 
occurs outside of target window (400x400)."));
QVERIFY(match.hasMatch());

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseMove(, QPoint(600, 600));

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseRelease(, Qt::LeftButton, Qt::NoModifier, QPoint(600, 
600));
}

Output:

* Start testing of Test *
Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 
shared (dynamic) debug build; by MSVC 2017)
PASS   : Test::initTestCase()
WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target 
window (400x400).
WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target 
window (400x400).
INFO   : Test::test_case1() Did not receive any message matching: ".*Mouse 
event at .* occurs outside of target window.*"
INFO   : Test::test_case1() Did not receive any message matching: ".*Mouse 
event at .* occurs outside of target window.*"
FAIL!  : Test::test_case1() Not all expected messages were received
PASS   : Test::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms
* Finished testing of Test *

Mouse move and release events occurring outside of a window is not uncommon, so 
there should be a way to disable these warnings.

Using QTest::ignoreWarning() has no effect here, because the message logger 
system is (probably intentionally) bypassed.

Does anyone know why this is the case?

Also, does anyone have any ideas about how to solve this?

One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be 
a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow 
halfway through a "drag" loop.

Another idea could be to have a flag or construct that only applies for the 
duration of a test function, and is reset at the end of that function. I think 
something like this could also be useful for the opposite use case: failing a 
test upon any warnings (something that would be useful for QML applications). 
Something like https://codereview.qt-project.org/#/c/89178/ except it's 
automatically reset for you at the end of each test.
___
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] qdds image format

[Иван Комиссаров]

So, how those issues are checked? Any tool or what?

2018-04-16 0:41 GMT+03:00 Thiago Macieira :

> On Sunday, 15 April 2018 12:59:35 PDT Giuseppe D'Angelo wrote:
> > Hello,
> >
> > Il 15/04/2018 18:14, Иван Комиссаров ha scritto:
> > >> The usual amount of parsing a file without doing bounds checks, so
> making
> > >> the user vulnerable to crashes / code execution / overflows and the
> > >> like.>
> > > Are there any tickets on Jira related? All tickets i found are fixed
> and
> > > closed long ago (Qt5.5)
> > I'm not sure if it was reported on Jira or through a security
> > notification. I'm thinking about the latter, around the time where we
> > fuzzed Qt's image formats.
>
> I don't think it was reported against DDS. We fuzzed all the image format
> readers after a report against one of them.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> 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

[Development] QTestLib: sending mouse move and release events outside windows

[Mitch Curtis]

https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move 
and release events outside of a window causes warnings:

void Test::test_case1()
{
QWindow window;
window.resize(400, 400);

// Start inside and drag outside (e.g. moving a selection to the edge of a
// canvas should scroll the canvas).
QTest::mousePress(, Qt::LeftButton, Qt::NoModifier, QPoint(200, 
200));

const QRegularExpression regex(".*Mouse event at .* occurs outside of 
target window.*");
QVERIFY(regex.isValid());

const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 
occurs outside of target window (400x400)."));
QVERIFY(match.hasMatch());

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseMove(, QPoint(600, 600));

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseRelease(, Qt::LeftButton, Qt::NoModifier, QPoint(600, 
600));
}

Output:

* Start testing of Test *
Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 
shared (dynamic) debug build; by MSVC 2017)
PASS   : Test::initTestCase()
WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target 
window (400x400).
WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target 
window (400x400).
INFO   : Test::test_case1() Did not receive any message matching: ".*Mouse 
event at .* occurs outside of target window.*"
INFO   : Test::test_case1() Did not receive any message matching: ".*Mouse 
event at .* occurs outside of target window.*"
FAIL!  : Test::test_case1() Not all expected messages were received
PASS   : Test::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms
* Finished testing of Test *

Mouse move and release events occurring outside of a window is not uncommon, so 
there should be a way to disable these warnings.

Using QTest::ignoreWarning() has no effect here, because the message logger 
system is (probably intentionally) bypassed.

Does anyone know why this is the case?

Also, does anyone have any ideas about how to solve this?

One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be 
a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow 
halfway through a "drag" loop.

Another idea could be to have a flag or construct that only applies for the 
duration of a test function, and is reset at the end of that function. I think 
something like this could also be useful for the opposite use case: failing a 
test upon any warnings (something that would be useful for QML applications). 
Something like https://codereview.qt-project.org/#/c/89178/ except it's 
automatically reset for you at the end of each test.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Jani Heikkinen]

Hi!

Keeping release tags is OK for me. Motivation behind my proposal was to stop 
planning other release dates than FF & final target. Currently we are trying to 
estimate also alpha, beta and RC release dates and it seems to cause some 
delays for us: persons aren't fixing blocker issues or doing the test because 
it seems there is a time to do that later (because e.g RC date is planned to be 
after a month). So if the way to go is to do these "releases" immediately when 
ready it might help us to get fixes in earlier and so on also get releases out 
quicker...

But this change doesn't meant we need to stop calling those releases as Alpha 
or Betas so we can continue labeling those as earlier. 

br,
Jani


> -Original Message-
> From: Development  project.org> On Behalf Of Lars Knoll
> Sent: maanantai 16. huhtikuuta 2018 10.03
> To: Simon Hausmann 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for release
> process change
> 
> Hi,
> 
> From a releasing perspective I agree that the set we should update our
> packages often. We should also stop delivering source only alpha packages,
> and have binaries from the get go.
> 
> But from a user perspective, I agree that it's good and important to put a
> name to those releases so people know what to expect from them.
> Snapshots as long as the packages are created from the dev branch, then
> alpha, beta, RC and final. We could discuss whether we need the alpha label,
> or whether we can go directly to beta, but I believe that we do need the
> other tags.
> 
> But I do agree with releasing packages as often as possible, and we should
> have them already before FF from the dev branch (if possible).
> 
> So I’d propose to have our packages updated often. But we do keep the
> ‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags.
> 
> - Snapshot packages from the dev branch
> - FF and branching occur together and packages are getting the ‘alpha’ tag
> - Agree that we should start with the API review immediately.
> - Beta once API review is done
> - RC once we have the release branch and all currently known blockers are
> fixed
> 
> That should be pretty close to what Jani described, only that we keep the
> tags for our users.
> 
> Cheers,
> Lars
> 
> > On 16 Apr 2018, at 08:43, Simon Hausmann 
> wrote:
> >
> > Hi,
> >
> > Same here. At first this seemed like a good idea, but it becomes awkward
> when you look at it from the dev workflow point of view: After fixing a bug,
> what is the fix version? Reported in snapshot-24062918 and fixed in
> snapshot-14072918? That sounds like it would create a mess in JIRA.
> >
> > Unless of course the task of assigning the fix version field was automated.
> >
> > Simon
> >
> > On 16. Apr 2018, at 08:12, Alex Blasche  wrote:
> >
> >>> -Original Message-
>  On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote:
>  And at this same time I want to propose that we stop delivering
>  alpha or beta releases and just do snapshots instead. Publishing
>  regular snapshots should be done until we are ready for RC. That
>  because I don't see that much need for those anymore. Those are
>  nowadays kind of milestones and in my opinion makes whole process a
>  bit unclear/difficult (we don't have very good definitions for
>  Alpha and Beta
> >>> releases).
> >>>
> >>> Yes we do.
> >>>
> >>> Alpha means feature complete, asking for feedback on the API and new
> >>> functionality.
> >>>
> >>> Beta means implementation complete, asking for feedback on the
> >>> quality of the implementation, seeking bugs and regressions to be fixed.
> >>>
> >>> RC means we've fixed everything we knew.
> >>
> >> I wholeheartedly agree with Thiago. The distinction may not make a
> difference from the release team perspective but it makes a world of
> difference for developers (who have different limitations for each step) and
> the world as they can decide how bleeding edge the code is that they want
> to test.
> >>
> >> I have a problem with the motivation behind this suggestion too (don't
> understand it). The naming makes no difference for you as release manager
> (afaict just a label). Why suggesting it aka what do you want to gain by doing
> snapshots only?
> >> --
> >> Alex
> >>
> >> ___
> >> 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
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Edward Welbourne]

Tuukka Turunen (16 April 2018 08:59)
> I very much like continuous flow of snapshots.

I don't think anyone is challenging that part of the plan.
The only objection to the plan has been to the change in naming.

> Sometimes we have a tendency to fall into a "let's wait and get still
> this one fix in" mode, which is very inefficient. It is beneficial
> when making .x patch releases and the fix is for a regression. But in
> other situations, it is typically more important to have a frequent
> flow of releases.

Frequency of builds is orthogonal to how we name them.
Build early, build often.  That is good.
Make the status of each build clear by tagging it alpha, beta or RC if
it meets the criteria Thiago gave.
Number them any way you like, but keep these distinctions.
They are useful to consumers.

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

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Lars Knoll]

Hi,

From a releasing perspective I agree that the set we should update our packages 
often. We should also stop delivering source only alpha packages, and have 
binaries from the get go. 

But from a user perspective, I agree that it's good and important to put a name 
to those releases so people know what to expect from them. Snapshots as long as 
the packages are created from the dev branch, then alpha, beta, RC and final. 
We could discuss whether we need the alpha label, or whether we can go directly 
to beta, but I believe that we do need the other tags.

But I do agree with releasing packages as often as possible, and we should have 
them already before FF from the dev branch (if possible).

So I’d propose to have our packages updated often. But we do keep the 
‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags.

- Snapshot packages from the dev branch
- FF and branching occur together and packages are getting the ‘alpha’ tag
- Agree that we should start with the API review immediately.
- Beta once API review is done
- RC once we have the release branch and all currently known blockers are fixed

That should be pretty close to what Jani described, only that we keep the tags 
for our users.

Cheers,
Lars

> On 16 Apr 2018, at 08:43, Simon Hausmann  wrote:
> 
> Hi,
> 
> Same here. At first this seemed like a good idea, but it becomes awkward when 
> you look at it from the dev workflow point of view: After fixing a bug, what 
> is the fix version? Reported in snapshot-24062918 and fixed in 
> snapshot-14072918? That sounds like it would create a mess in JIRA.
> 
> Unless of course the task of assigning the fix version field was automated.
> 
> Simon
> 
> On 16. Apr 2018, at 08:12, Alex Blasche  wrote:
> 
>>> -Original Message-
 On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote:
 And at this same time I want to propose that we stop delivering alpha
 or beta releases and just do snapshots instead. Publishing regular
 snapshots should be done until we are ready for RC. That because I
 don't see that much need for those anymore. Those are nowadays kind of
 milestones and in my opinion makes whole process a bit
 unclear/difficult (we don't have very good definitions for Alpha and Beta
>>> releases).
>>> 
>>> Yes we do.
>>> 
>>> Alpha means feature complete, asking for feedback on the API and new
>>> functionality.
>>> 
>>> Beta means implementation complete, asking for feedback on the quality of 
>>> the
>>> implementation, seeking bugs and regressions to be fixed.
>>> 
>>> RC means we've fixed everything we knew.
>> 
>> I wholeheartedly agree with Thiago. The distinction may not make a 
>> difference from the release team perspective but it makes a world of 
>> difference for developers (who have different limitations for each step) and 
>> the world as they can decide how bleeding edge the code is that they want to 
>> test.
>> 
>> I have a problem with the motivation behind this suggestion too (don't 
>> understand it). The naming makes no difference for you as release manager 
>> (afaict just a label). Why suggesting it aka what do you want to gain by 
>> doing snapshots only?
>> --
>> Alex
>> 
>> ___
>> 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

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

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Ville Voutilainen]

On 16 April 2018 at 09:43, Simon Hausmann  wrote:
> Hi,
>
> Same here. At first this seemed like a good idea, but it becomes awkward when 
> you look at it from the dev workflow point of view: After fixing a bug, what 
> is the fix version? Reported in snapshot-24062918 and fixed in 
> snapshot-14072918? That sounds like it would create a mess in JIRA.


That problem seems surmountable; if I have a fix for a bug that
appears in an "5.9.6 alpha", I'm not going to set its fix version to
"5.9.6 beta", I'm going
to set it to 5.9.6.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Tuukka Turunen]

Hi,

I very much like continuous flow of snapshots. Sometimes we have a tendency to 
fall into a "let's wait and get still this one fix in" mode, which is very 
inefficient. It is beneficial when making .x patch releases and the fix is for 
a regression. But in other situations, it is typically more important to have a 
frequent flow of releases. From that viewpoint I support what Jani proposed. 
Every period of wait we add makes the release process: 1. longer and 2. 
unpredicted. We should aim to make the process of creating a new feature 
release of Qt faster than it is today, so challenging the current process is a 
good thing. 

We are working on enabling regular snapshots from dev, with target of moving 
more development and interoperability testing to dev (and thus adding the 
maturity of dev, making it easier to develop with etc). After these are in 
place, we have snapshots rolling from all branches of a release. 

With dev snapshots in place, I agree with Jani and think we could:
- Discontinue the concept of an 'Alpha' release of a new Qt version starting 
from Qt 5.12 (in a way every dev snapshot is a pre-release of Qt 5.12)
- After branching to 5.12, call the first released snapshot Qt 5.12 Beta 1 (or 
use build number)
- After branching to 5.12.0, call the first released snapshot Qt 5.12 RC 1 (or 
use build number)

With this we would focus the activities more into moving to a new branch - and 
of course keep (and even improve) the existing criteria when we are ready to 
branch. Use of build numbers instead of Beta 1 etc is also fine for me, if 
preferred.

Yours,

Tuukka

On 16/04/2018, 9.44, "Development on behalf of Simon Hausmann" 
 wrote:

Hi,

Same here. At first this seemed like a good idea, but it becomes awkward 
when you look at it from the dev workflow point of view: After fixing a bug, 
what is the fix version? Reported in snapshot-24062918 and fixed in 
snapshot-14072918? That sounds like it would create a mess in JIRA.

Unless of course the task of assigning the fix version field was automated.

Simon

On 16. Apr 2018, at 08:12, Alex Blasche  wrote:

>> -Original Message-
>>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote:
>>> And at this same time I want to propose that we stop delivering alpha
>>> or beta releases and just do snapshots instead. Publishing regular
>>> snapshots should be done until we are ready for RC. That because I
>>> don't see that much need for those anymore. Those are nowadays kind of
>>> milestones and in my opinion makes whole process a bit
>>> unclear/difficult (we don't have very good definitions for Alpha and 
Beta
>> releases).
>> 
>> Yes we do.
>> 
>> Alpha means feature complete, asking for feedback on the API and new
>> functionality.
>> 
>> Beta means implementation complete, asking for feedback on the quality 
of the
>> implementation, seeking bugs and regressions to be fixed.
>> 
>> RC means we've fixed everything we knew.
> 
> I wholeheartedly agree with Thiago. The distinction may not make a 
difference from the release team perspective but it makes a world of difference 
for developers (who have different limitations for each step) and the world as 
they can decide how bleeding edge the code is that they want to test.
> 
> I have a problem with the motivation behind this suggestion too (don't 
understand it). The naming makes no difference for you as release manager 
(afaict just a label). Why suggesting it aka what do you want to gain by doing 
snapshots only?
> --
> Alex
> 
> ___
> 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


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

Re: [Development] Qt 5.12 schedule proposal & proposal for release process change

[Simon Hausmann]

Hi,

Same here. At first this seemed like a good idea, but it becomes awkward when 
you look at it from the dev workflow point of view: After fixing a bug, what is 
the fix version? Reported in snapshot-24062918 and fixed in snapshot-14072918? 
That sounds like it would create a mess in JIRA.

Unless of course the task of assigning the fix version field was automated.

Simon

On 16. Apr 2018, at 08:12, Alex Blasche  wrote:

>> -Original Message-
>>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote:
>>> And at this same time I want to propose that we stop delivering alpha
>>> or beta releases and just do snapshots instead. Publishing regular
>>> snapshots should be done until we are ready for RC. That because I
>>> don't see that much need for those anymore. Those are nowadays kind of
>>> milestones and in my opinion makes whole process a bit
>>> unclear/difficult (we don't have very good definitions for Alpha and Beta
>> releases).
>> 
>> Yes we do.
>> 
>> Alpha means feature complete, asking for feedback on the API and new
>> functionality.
>> 
>> Beta means implementation complete, asking for feedback on the quality of the
>> implementation, seeking bugs and regressions to be fixed.
>> 
>> RC means we've fixed everything we knew.
> 
> I wholeheartedly agree with Thiago. The distinction may not make a difference 
> from the release team perspective but it makes a world of difference for 
> developers (who have different limitations for each step) and the world as 
> they can decide how bleeding edge the code is that they want to test.
> 
> I have a problem with the motivation behind this suggestion too (don't 
> understand it). The naming makes no difference for you as release manager 
> (afaict just a label). Why suggesting it aka what do you want to gain by 
> doing snapshots only?
> --
> Alex
> 
> ___
> 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] Qt 5.12 schedule proposal & proposal for release process change

[Alex Blasche]

> -Original Message-
> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote:
> > And at this same time I want to propose that we stop delivering alpha
> > or beta releases and just do snapshots instead. Publishing regular
> > snapshots should be done until we are ready for RC. That because I
> > don't see that much need for those anymore. Those are nowadays kind of
> > milestones and in my opinion makes whole process a bit
> > unclear/difficult (we don't have very good definitions for Alpha and Beta
> releases).
> 
> Yes we do.
> 
> Alpha means feature complete, asking for feedback on the API and new
> functionality.
> 
> Beta means implementation complete, asking for feedback on the quality of the
> implementation, seeking bugs and regressions to be fixed.
> 
> RC means we've fixed everything we knew.

I wholeheartedly agree with Thiago. The distinction may not make a difference 
from the release team perspective but it makes a world of difference for 
developers (who have different limitations for each step) and the world as they 
can decide how bleeding edge the code is that they want to test.

I have a problem with the motivation behind this suggestion too (don't 
understand it). The naming makes no difference for you as release manager 
(afaict just a label). Why suggesting it aka what do you want to gain by doing 
snapshots only?
--
Alex

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