Re: [Development] Windows: Trying to join to a multicast group as a receiver with specific interface always uses default interface

[Thiago Macieira]

Em sexta-feira, 27 de janeiro de 2017, às 00:57:37 PST, David Callu escreveu:
> Hi,
> 
> I spend 3 day to search, fix and test my patch for this bug.
> I finally found 3 Issue about it :

First of all, are you joining an IPv4 multicast group or an IPv6 one?

If it is IPv4, the priority for your issue has just dropped to the floor. I 
won't debug IPv4 multicast on Windows, on principle.

If it is IPv6, I'll do it.

> but the code review of this patch :
> https://codereview.qt-project.org/#/c/112854/
> have the status
> 
> *Abandoned.*
> This bug is here seen 2011, from the Initial import from the monolithic
> Qt.commit.
> 
> Why did this patch is abandoned ?

I don't know.

> What can i do to reactive it ?

I've just asked Andy to do it. If he doesn't do it, you can submit the fix 
yourself.

> If it is not correct, what can I do to fix it ?

Debug and submit your patch, if this one doesn't do it.

I will review IPv4 patches, but I will not lift a finger to test 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] Windows: Trying to join to a multicast group as a receiver with specific interface always uses default interface

[David Callu]

Hi,

I spend 3 day to search, fix and test my patch for this bug.
I finally found 3 Issue about it :

https://bugreports.qt.io/browse/QTBUG-53127
https://bugreports.qt.io/browse/QTBUG-45646
https://bugreports.qt.io/browse/QTBUG-30949

QTBUG-45646 have a patch that fix the bug. I did a similare patch on my own
and it work fine on windows.


but the code review of this patch :
https://codereview.qt-project.org/#/c/112854/
have the status

*Abandoned.*
This bug is here seen 2011, from the Initial import from the monolithic
Qt.commit.

Why did this patch is abandoned ?
What can i do to reactive it ?

If it is not correct, what can I do to fix it ?


Regards

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

Re: [Development] Qt5 k1om x100 Xeon PHI Cross Compilation

[Robert Pancoast]

Greetings Thiago,

I will take a closer look and get this functioning with latest dev branch from 
qt/qtbase. 

Thanks,
Rob



> On Jan 26, 2017, at 6:33 PM, Thiago Macieira  
> wrote:
> 
>> Em quinta-feira, 26 de janeiro de 2017, às 14:19:15 PST, ƦOB COASTN escreveu:
>> Greetings Konstantin,
>> 
>> I appreciate the insight/direction and will rework patches for the 5.8.0
>> codebase.
> 
> 5.8.0 is too old for that already. Please base your patches on the latest 5.8 
> branch.
> 
> I've just tried to build things with -mmic and I can't get anything linking. 
> I 
> should probably follow the instructions, but I couldn't be bothered to look 
> for 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

Re: [Development] Qt5 k1om x100 Xeon PHI Cross Compilation

[Thiago Macieira]

Em quinta-feira, 26 de janeiro de 2017, às 14:19:15 PST, ƦOB COASTN escreveu:
> Greetings Konstantin,
> 
> I appreciate the insight/direction and will rework patches for the 5.8.0
> codebase.

5.8.0 is too old for that already. Please base your patches on the latest 5.8 
branch.

I've just tried to build things with -mmic and I can't get anything linking. I 
should probably follow the instructions, but I couldn't be bothered to look 
for 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] QQmlListProperty: static_assert that T inherits QObject

[Milian Wolff]

Hey all,

the QQmlListProperty states:

"Note: QQmlListProperty can only be used for lists of QObject-derived object 
pointers."

Since I am bad at reading documentation, I previously tried (I think multiple 
times) to do something like:

QQmlListProperty

or even

QQmlListProperty

This happily compiles and only at runtime does it not work. So I thought I'd 
add a static assert to QQmlListProperty to check this at compile time:

https://codereview.qt-project.org/#/c/183631/

But this uncovered this gem inside qtdeclarative itself:

qqmlobjectcreator_p.h:
158:QQmlListProperty _currentList;

Uhm, a void* list, really? Should this be a QQmlListProperty?

Digging further, I find a few places where QQmlListProperty is instantiated 
for non-QObjects, mostly within qmlRegisterUncreateableType, which is easy to 
prevent by leveraging std::enable_if.

Digging even further, I hit the first road-block though with my approach: 
Adding the static assert directly to QQmlListProperty means that T must be 
fully defined when the list property gets used. Does this make this change 
source-incompatible? Is there a workaround for this? I fixed the issues inside 
Qt Declarative itself, but I wonder whether this is acceptable for existing 
users of QQmlListProperty outside of QtDeclarative.

The second road-block comes when compiling the tests - apparently 
QQmlListProperty also works with interfaces! So I added another type trait for 
that. Is that acceptable?

Thanks

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt 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] Qt5 k1om x100 Xeon PHI Cross Compilation

[ƦOB COASTN]

Greetings Konstantin,

I appreciate the insight/direction and will rework patches for the 5.8.0
codebase.

Thanks,
Rob


On Thu, Jan 26, 2017 at 2:06 PM, Konstantin Tokarev 
wrote:

>
>
> 26.01.2017, 22:00, "ƦOB COASTN" :
> > Greetings,
> >
> > The cross-compilation of Qt5 and additional modules adds support for
> headless Qt5 applications to run as native k1om co-processor applications.
> >
> > Files that required modification include 'configure' and
> 'mkspecs/linux-icc/qmake.conf'
> >
> > Reference:
> > https://github.com/mancoast/qtbase/commit/30001050bea670dc1dad7d10d45ea4
> 1be717ff46
> >
> > I think it should be possible to create a new
> 'mkspecs/linux-icc-k1om/qmake.conf'.
> >
> > Any thoughts for reworking the changes to  'configure' ?
>
> configure was largely reworked for Qt 5.8, your patch is against old
> version
>
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtgamepad Support for Microsoft Xbox 360 Wireless Receiver+Controller

[ƦOB COASTN]

Hello Andy,

Thanks for the quick response.
Let's continue this discussion in the appropriate mailing list.

Reference:
http://lists.qt-project.org/pipermail/interest/2017-January/025940.html

Thanks,
Rob

On Thu, Jan 26, 2017 at 1:19 PM, Andy Nichols  wrote:

> Hi,
>
>
>
>1. I’ve not confirmed if QtGamepad works for Windows Server 2012 (not
>sure what kernel that is, but not a supported platform that I know of).
>Should world anyway though.
>2. Yes, QtGamepad definitely works with Xbox 360 and Xbox One
>controllers.  It is designed to after the SDL Gamepad API which makes all
>game controllers look/map to Xbox 360 controllers.
>3. This is actually expected behavior.  The Configuration example
>depends on the backend supporting re-mapping.  That only works with the
>evdev backend.  The Xinput backend doesn’t support configuring the mapping
>of the controller, but you shouldn’t need to giving that you already are
>using a supported controller.  Rather if you want different aliases for
>buttons pressed you would handle that in your applications.
>4. That combination is known to work (that’s what I wrote it
>for/with).  I was not using the server version of windows, but rather the
>standard Windows 7, 8, 10 kernels.
>
>
>
> Actually Base of what you said things sound like they are working
> already.  I think there is an existing bug report for the Xinput backend
> for not reporting connecting and disconnecting properly.  It still should
> handle multiple connected controllers and the inputs for each, but might
> not send the connected and disconnected signals.
>
>
>
> I guess I should also mention that this mailing list isn’t the correct
> place for this kind of inquiry, as this is about the development of Qt, and
> not the usage of Qt.
>
>
>
> Regards,
>
> Andy Nichols
>
>
>
> *From:* Development [mailto:development-bounces+andy.nichols=
> qt...@qt-project.org] *On Behalf Of *?OB COASTN
> *Sent:* Thursday, January 26, 2017 6:49 PM
> *To:* development@qt-project.org
> *Subject:* [Development] qtgamepad Support for Microsoft Xbox 360
> Wireless Receiver+Controller
>
>
>
> Greetings,
>
>
>
> This is my first post to qt-project mailing list.
>
> The information provided on https://github.com/qt/qtgamepad states:
>
> Supported Platforms: Native Backends
>
> Linux (evdev)
>
> Window (xinput)
>
> Android
>
>
>
> I aim to develop QTgamepad on Windows Server 2012R2.
>
>
>
> 1.) Has the latest QTgamepad build been confirmed to function with Windows
> Server 2012R2?
>
> 2.) Has the latest QTgamepad build been confirmed to function with Xbox
> Controllers?
>
>
>
> Currently QTgamepad 5.7.1 on Windows Server 2012R2 fails to operate
> correctly.
>
> The "Qt Gamepad Configure Buttons Example" compiles and runs, but the
> connected Gamepads drop down never populates.
>
> However, the values for the gamepad input accurately reflect button and
> stick status.
>
>
>
> It seems that something is not properly functioning with the
> "GamepadManager.connectedGamepads".
>
>
>
> 3.) Any advice for troubleshooting?
>
> 4.) Is there a recommended Windows Operating System known to work with the
> latest QTgamepad build and Microsoft Xbox 360 Wireless Receiver+Controller?
>
>
>
> Thanks,
>
> Rob
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Improve performance (listview + onVerticalVelocityChanged)

[Bernhard B]

I think I solved my problem. In case someone is interested, that's my
solution:

//hide "back to top" button when movement ended and we are

//at index 0

onMovementEnded: {
if(indexAt(contentX, contentY) === 0){

  backToTopButton.visible = false;

  }

}

onFlickStarted: {

//when user scrolls fast enough up, show the tab bar

//and the "back to top" button

if(verticalVelocity < -flickTabBarTreshold) {

backToTopButton.visible = true;

tabBar.show();

}


//when user scrolls fast enough down hide "back to top" button

//and the tab bar

if(verticalVelocity > flickTabBarTreshold){

backToTopButton.visible = false;

tabBar.hide();

}

}

I don't know if this is the best solution, but it seems to work.

Thanks,
Bernhard

2017-01-26 15:38 GMT+01:00 Bernhard B :

> Hi,
>
> I am currently trying to optimize my Listview for performance. I already
> removed most of the bottlenecks by following the great recommendations at:
> http://doc.qt.io/qt-5/qtquick-performance.html
>
> However, there is one problem I don't how to solve. It's about this code
> part:
>
> ListView{
> clip: true
> property real flickTabBarTreshold;
>
> Component.onCompleted: {
> flickTabBarTreshold = (2/3) * maximumFlickVelocity;
> }
>
> onVerticalVelocityChanged: {
>
>
> //when user scrolls fast enough up, show the tab bar //and the "back 
> to top" button
>
> if(verticalVelocity < -flickTabBarTreshold) {
> backToTopButton.visible = true;
>
> tabBar.show();
>
> }
>
>
>
> //when user scrolls fast enough down hide "back to top" button//and 
> the tab bar
> if(verticalVelocity > flickTabBarTreshold){
>
> backToTopButton.visible = false;
>
> tabBar.hide();
>
> }
>
> //always disable "back to top button" when top reached
> if(indexAt(contentX, contentY) === 0)backToTopButton.visible = false;
>
> }
> }
>
> This part is one of the biggest performance bottlenecks at the moment (as
> it gets called a lot of times) and has a significant impact on the
> scrolling behavior (lagging).
>
> My idea was to put that code somehow in my C++ Listmodel and emit only a
> signal when something actually changed.
>
> For the last part
>
> //always disable "back to top button" when top reachedif(indexAt(contentX, 
> contentY) === 0)   backToTopButton.visible = false;
>
>
> I think it should be possible to check that in the
> QVariant  QAbstractItemModel::data(const
> QModelIndex  &*index*, int *role*
> = Qt::DisplayRole) const
>
> method. When index.row() === 0, I a signal will be emitted. In QML I am
> connecting on that signal and execute  backToTopButton.visible = false;
>
> I haven't tested it yet, but I think it should work.
>
> For the other two conditions however, I am a little bit clueless.
>
> Does anyone of you guys maybe have an idea on how to improve that?
>
> Any help is really appreciated.
>
>
> Thanks,
>
> Bernhard
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 k1om x100 Xeon PHI Cross Compilation

[Konstantin Tokarev]

26.01.2017, 22:00, "ƦOB COASTN" :
> Greetings,
>
> The cross-compilation of Qt5 and additional modules adds support for headless 
> Qt5 applications to run as native k1om co-processor applications.
>
> Files that required modification include 'configure' and 
> 'mkspecs/linux-icc/qmake.conf'
>
> Reference:
> https://github.com/mancoast/qtbase/commit/30001050bea670dc1dad7d10d45ea41be717ff46
>
> I think it should be possible to create a new 
> 'mkspecs/linux-icc-k1om/qmake.conf'.
>
> Any thoughts for reworking the changes to  'configure' ?

configure was largely reworked for Qt 5.8, your patch is against old version


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

[Development] Qt5 k1om x100 Xeon PHI Cross Compilation

[ƦOB COASTN]

Greetings,

The cross-compilation of Qt5 and additional modules adds support for
headless Qt5 applications to run as native k1om co-processor applications.

Files that required modification include 'configure
'
and 'mkspecs/linux-icc/qmake.conf'

Reference:
https://github.com/mancoast/qtbase/commit/30001050bea670dc1dad7d10d45ea41be717ff46

I think it should be possible to create a new
'mkspecs/linux-icc-k1om/qmake.conf'.

Any thoughts for reworking the changes to  'configure' ?


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

Re: [Development] qtgamepad Support for Microsoft Xbox 360 Wireless Receiver+Controller

[Andy Nichols]

Hi,


  1.  I’ve not confirmed if QtGamepad works for Windows Server 2012 (not sure 
what kernel that is, but not a supported platform that I know of).  Should 
world anyway though.
  2.  Yes, QtGamepad definitely works with Xbox 360 and Xbox One controllers.  
It is designed to after the SDL Gamepad API which makes all game controllers 
look/map to Xbox 360 controllers.
  3.  This is actually expected behavior.  The Configuration example depends on 
the backend supporting re-mapping.  That only works with the evdev backend.  
The Xinput backend doesn’t support configuring the mapping of the controller, 
but you shouldn’t need to giving that you already are using a supported 
controller.  Rather if you want different aliases for buttons pressed you would 
handle that in your applications.
  4.  That combination is known to work (that’s what I wrote it for/with).  I 
was not using the server version of windows, but rather the standard Windows 7, 
8, 10 kernels.

Actually Base of what you said things sound like they are working already.  I 
think there is an existing bug report for the Xinput backend for not reporting 
connecting and disconnecting properly.  It still should handle multiple 
connected controllers and the inputs for each, but might not send the connected 
and disconnected signals.

I guess I should also mention that this mailing list isn’t the correct place 
for this kind of inquiry, as this is about the development of Qt, and not the 
usage of Qt.

Regards,
Andy Nichols

From: Development 
[mailto:development-bounces+andy.nichols=qt...@qt-project.org] On Behalf Of ?OB 
COASTN
Sent: Thursday, January 26, 2017 6:49 PM
To: development@qt-project.org
Subject: [Development] qtgamepad Support for Microsoft Xbox 360 Wireless 
Receiver+Controller

Greetings,

This is my first post to qt-project mailing list.
The information provided on https://github.com/qt/qtgamepad states:
Supported Platforms: Native Backends
Linux (evdev)
Window (xinput)
Android

I aim to develop QTgamepad on Windows Server 2012R2.

1.) Has the latest QTgamepad build been confirmed to function with Windows 
Server 2012R2?
2.) Has the latest QTgamepad build been confirmed to function with Xbox 
Controllers?

Currently QTgamepad 5.7.1 on Windows Server 2012R2 fails to operate correctly.
The "Qt Gamepad Configure Buttons Example" compiles and runs, but the connected 
Gamepads drop down never populates.
However, the values for the gamepad input accurately reflect button and stick 
status.

It seems that something is not properly functioning with the 
"GamepadManager.connectedGamepads".

3.) Any advice for troubleshooting?
4.) Is there a recommended Windows Operating System known to work with the 
latest QTgamepad build and Microsoft Xbox 360 Wireless Receiver+Controller?

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

[Development] qtgamepad Support for Microsoft Xbox 360 Wireless Receiver+Controller

[ƦOB COASTN]

Greetings,

This is my first post to qt-project mailing list.
The information provided on https://github.com/qt/qtgamepad states:
Supported Platforms: Native Backends
Linux (evdev)
Window (xinput)
Android

I aim to develop QTgamepad on Windows Server 2012R2.

1.) Has the latest QTgamepad build been confirmed to function with Windows
Server 2012R2?
2.) Has the latest QTgamepad build been confirmed to function with Xbox
Controllers?

Currently QTgamepad 5.7.1 on Windows Server 2012R2 fails to operate
correctly.
The "Qt Gamepad Configure Buttons Example" compiles and runs, but the
connected Gamepads drop down never populates.
However, the values for the gamepad input accurately reflect button and
stick status.

It seems that something is not properly functioning with the
"GamepadManager.connectedGamepads".

3.) Any advice for troubleshooting?
4.) Is there a recommended Windows Operating System known to work with the
latest QTgamepad build and Microsoft Xbox 360 Wireless Receiver+Controller?

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

[Development] Improve performance (listview + onVerticalVelocityChanged)

[Bernhard B]

Hi,

I am currently trying to optimize my Listview for performance. I already
removed most of the bottlenecks by following the great recommendations at:
http://doc.qt.io/qt-5/qtquick-performance.html

However, there is one problem I don't how to solve. It's about this code
part:

ListView{
clip: true
property real flickTabBarTreshold;

Component.onCompleted: {
flickTabBarTreshold = (2/3) * maximumFlickVelocity;
}

onVerticalVelocityChanged: {


//when user scrolls fast enough up, show the tab bar //and the
"back to top" button

if(verticalVelocity < -flickTabBarTreshold) {
backToTopButton.visible = true;

tabBar.show();

}



//when user scrolls fast enough down hide "back to top" button
//and the tab bar
if(verticalVelocity > flickTabBarTreshold){

backToTopButton.visible = false;

tabBar.hide();

}

//always disable "back to top button" when top reached
if(indexAt(contentX, contentY) === 0)backToTopButton.visible =
false;

}
}

This part is one of the biggest performance bottlenecks at the moment (as
it gets called a lot of times) and has a significant impact on the
scrolling behavior (lagging).

My idea was to put that code somehow in my C++ Listmodel and emit only a
signal when something actually changed.

For the last part

//always disable "back to top button" when top
reachedif(indexAt(contentX, contentY) === 0)   backToTopButton.visible
= false;


I think it should be possible to check that in the
QVariant  QAbstractItemModel::data(const
QModelIndex  &*index*, int *role* =
Qt::DisplayRole) const

method. When index.row() === 0, I a signal will be emitted. In QML I am
connecting on that signal and execute  backToTopButton.visible = false;

I haven't tested it yet, but I think it should work.

For the other two conditions however, I am a little bit clueless.

Does anyone of you guys maybe have an idea on how to improve that?

Any help is really appreciated.


Thanks,

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

[Development] Branch request for Qt 3D

[Sean Harmer]

Hi,

Could somebody create me a new wip/physics branch for the Qt 3D branched off 
of dev please? This is to start preparing a physics aspect hopefully for Qt 
5.10.

The existing wip/animation and wip/qtquickintegration branches should be going 
away shortly to keep things under control.

Thanks in advance,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Change file process & improvement proposal

[Kai Koehne]

> -Original Message-
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, January 26, 2017 12:52 PM
> To: development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Releasing] [Development] Change file process & improvement
> proposal
> 
> On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote:
> > I don't know what you're saying, much less why it's supposed to be the
> > obvious interpretation.  A "tagged commit" is presumably v5.7.0 or
> > similar; why should a commit without an amends line be assumed to
> > relate to one of these ?
> >
> i used "tagged commit" as a shorthand for "a commit which is reachable from
> a tag", which should be fairly clear from the context. i.e., "git tag 
> --contains
> " returns something.

Well, I had a hard time deciphering this, too. 



Anyway, this all feels like we get side-tracked in details. To reiterate:

- We do (still) have a problem with our ChangeLog files
  * The quality of the entries, and the scope, greatly differs (between modules)
  * We do have a problem getting them in place on time for a release

Jani's proposal is to fix parts of this is to encourage committers and 
reviewers to write [ChangeLog] entries as part of the commit. This could be 
encouraged by
* Enabling the [ChangeLog] line by default in the commit template
* Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx)

For the sanity bot, either we decide that _every_ change has a [ChangeLog], or 
we try to make the bot intelligent enough to decide whether a commit needs a 
change log, or not. Parts of the discussion so far makes me think that this 
will be an uphill battle though.

So, any strong opinion against enforcing a [ChangeLog] line, with "[ChangeLog] 
-" for commits that don't need one?

Regards

Kai

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

Re: [Development] Change file process & improvement proposal

[Oswald Buddenhagen]

On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote:
> I don't know what you're saying, much less why it's supposed to be the
> obvious interpretation.  A "tagged commit" is presumably v5.7.0 or
> similar; why should a commit without an amends line be assumed to
> relate to one of these ?
> 
i used "tagged commit" as a shorthand for "a commit which is reachable
from a tag", which should be fairly clear from the context. i.e., "git
tag --contains " returns something.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Change file process & improvement proposal

[Edward Welbourne]

On Wed, Jan 25, 2017 at 10:21:09AM +0100, Edward Welbourne wrote:
>> However, you seem to be talking about *release* 5.x.0 rather than the
>> *branch* of that name, so I'm not really clear on what you're talking
>> about.

25 January 2017 12:13, Oswald Buddenhagen:
> i don't know how you arrived at this conclusion, but it isn't relevant
> to my reasoning anyway.

On the other hand, it's a fairly good clue to the possibility that I've
misunderstood what you were talking about.

>>> we could suppress the changelog enforcement for example by standardizing
>>> my "amends ." lines in the commit messages. if the reference is to
>>> a commit which has not been tagged yet, we know that users won't find it
>>> interesting.
>
>> I have never heard of these amends  lines; where are they
>> explained ?
>>
> git log --author=oswald

So a sort of after-the-fact fixup! tag.

>> In any case, users may find a change interesting even if there is no
>> specific earlier commit that can be pinned down [...]
>
> unsurprisingly, i think that the correct fallback in case of a missing
> reference is assuming that the commit relates to a tagged commit (if
> it's even a fix at all) and therefore complaining about a missing
> changelog.

I don't know what you're saying, much less why it's supposed to be the
obvious interpretation.  A "tagged commit" is presumably v5.7.0 or
similar; why should a commit without an amends line be assumed to relate
to one of these ?  I *can* see how an amends line would be a basis for
not demanding a changelog entry, though.

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