[Development] Qt 5.10 schedule etc
Hi all,
Kindly reminder: According to schedule we should have Qt 5.10 feature freeze
after a week, see https://wiki.qt.io/Qt_5.10_Release. So it is time to do
remaining finalizations to 5.10 new features now and focus to bug fixing after
that. Please fill new features page now as well
(https://wiki.qt.io/New_Features_in_Qt_5.10); it seems to be quite empty at the
moment.
And we should start soft branching today. But as Frederik informed yesterday we
are planning to do some changes to coin infrastructure during this week (see
http://lists.qt-project.org/pipermail/development/2017-July/030596.html). So
let's postpone the start of soft branching a bit and do it after coin infra
changes are in & working. Doing one more branch just now makes these coin
changes more difficult & most probably causes more delays in the future.
So the plan with 5.10 is following:
1. Let's keep the agreed ff as it is (8.8.2017)
2. Get first 5.10 binary snapshot from 'dev' out as soon as possible
3. Start soft branching (from 'dev' to '5.10') immediately after coin infra
changes are in & every branch ('5.6', 5.9' & 'dev') is working ok with infra
changes
4. Finalize branching (~ a week from soft branching)
5. Release Qt 5.10 alpha as soon as possible after the branching. We should be
able to do this quite quickly; As usual Alpha will be src packages only and we
can already create needed ones from 'dev'.
* Most probably we should be able to deliver binary snapshot with alpha as
well. If not just at same time then quite soon after the release...
br,
Jani
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Jesus Fernandez for Approver status
Congratulations to Jesus. Approver rights have been set. -- Alex > -Original Message- > From: Development [mailto:development- > bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Timur > Pocheptsov > Sent: Tuesday, 11 July 2017 14:07 > To: Qt development mailing list > Subject: [Development] Nominating Jesus Fernandez for Approver status > > I'd like to nominate Jesus Fernandez for Approver status. Among other things > Jesus is the author and the maintainer > > of qtnetworkauth module, he is actively contributing to qtcore, qtnetwork, > qtwebsockets, qsql, etc. He is also > > participating in the development of the WebGL QPA plugin. > > > > > This is his Gerrit dashboard: > > > > > https://codereview.qt- > project.org/#/q/owner:%22Jesus+Fernandez%22+status:merged,n,z > > > > > Best regards, > > Timur. > > > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Viktor Engelmann for Approver Status
Congratulations to Viktor. Approver rights have been granted. -- Alex > -Original Message- > From: Development [mailto:development- > bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Simon > Hausmann > Sent: Tuesday, 11 July 2017 13:25 > To: development@qt-project.org > Subject: [Development] Nominating Viktor Engelmann for Approver Status > > Hi, > > > > > I'd like to propose Viktor for approver status. Since August last year he's > been > contributing to QtWebEngine full-time. Based on my experience talking to him > and working with him, I trust him to review changes thoroughly and approve or > reject changes responsively. > > > > > > > > > > > Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Denis Shienkov for Approver status
Congratulations to Denis. Approver rights have been granted. -- Alex > -Original Message- > From: Development [mailto:development- > bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of André > Hartmann > Sent: Thursday, 6 July 2017 08:36 > To: development@qt-project.org; qt-crea...@qt-project.org > Subject: [Development] Nominating Denis Shienkov for Approver status > > I'd like to propose the nomination of Denis Shienkov for Approver status. > > Denis has been the maintainer of QtSerialPort for a long time now. > He also formed the architecture of QtSerialBus and provided several CAN > plugins > there. He further contributes to other parts of Qt and QtCreator and is > actively > reviewing other changes (for example he has constructively improved a lot of > my changes to QtSerialBus). > > This is his own Gerrit dashboard: > > https://codereview.qt- > project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.c > om%253E%22,n,z > > And these are his reviews: > > https://codereview.qt- > project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmai > l.com%253E%22,n,z > > Best regards, > André > ___ > 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] [BB++] 17 minutes long documentary
Last call here because like I promised, here's a 17 minutes long documentary on BB++ which now shows its internals: https://youtu.be/GrNDYWyasxg Regards, -Phil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] implicit sharing and iterators in qt containers
On segunda-feira, 31 de julho de 2017 15:35:15 PDT Mandeep Sandhu wrote: > Well, if fast lookup isn't necessary, then I guess such a "container" is > not really needed, and one can simply implement it using a > QLinkedList> (maybe with some added > restrictions). And that's what it should be (though QVector, not QLinkedList) and simply add the convenience functions for iteration and searching by key. -- 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
Re: [Development] implicit sharing and iterators in qt containers
> > > It's still a key-value store in which items are retrieved by key, which > is sort of the definition of a "map". It just has inefficient look-up. > Right. Since this (fast lookup) is so ubiquitous amongst map like containers, I thought this was expected from all associative containers. If not, as I said before, a QLinkedList> with some restrictions should suffice. -mandeep > > -- > Matthew > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] implicit sharing and iterators in qt containers
On Mon, Jul 31, 2017 at 2:57 PM, Thiago Macieira wrote: > On segunda-feira, 31 de julho de 2017 14:36:59 PDT Mandeep Sandhu wrote: > > > I'd expect to be able to use keys that do not define qHash or qLess. > > > > Why? > > My type key type may be or contain an opaque non-orderable type, which > would > make implementing both qHash and qLess impossible. Right now, if you have > such > a key type, you can't use QMap or QHash. Example type: QVariant. > > Therefore, for this new container to add something we currently do not > have, > it MUST NOT require either function. > Okay, I got your point now. Although wouldn't the user be expecting this, given that other containers (STL containers, python dicts) also impose the same constraints? Isn't it a fair trade-off for faster lookup? > > > Search would be O(n). So be it. > > > > Well it wouldn't be much of a "map" then, would it? > > Sure it would. There's nothing that requires associative containers to have > search times better than O(n). It just happens that both std::map and QMap > implements them at O(log n). Well, if fast lookup isn't necessary, then I guess such a "container" is not really needed, and one can simply implement it using a QLinkedList> (maybe with some added restrictions). -mandeep > > -- > 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] implicit sharing and iterators in qt containers
On 2017-07-31 17:36, Mandeep Sandhu wrote: >> I'd expect to be able to use keys that do not define qHash or qLess. > > Why? Why not? >> Search would be O(n). So be it. > > Well it wouldn't be much of a "map" then, would it? It's still a key-value store in which items are retrieved by key, which is sort of the definition of a "map". It just has inefficient look-up. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] implicit sharing and iterators in qt containers
On segunda-feira, 31 de julho de 2017 14:36:59 PDT Mandeep Sandhu wrote: > > I'd expect to be able to use keys that do not define qHash or qLess. > > Why? My type key type may be or contain an opaque non-orderable type, which would make implementing both qHash and qLess impossible. Right now, if you have such a key type, you can't use QMap or QHash. Example type: QVariant. Therefore, for this new container to add something we currently do not have, it MUST NOT require either function. > > Search would be O(n). So be it. > > Well it wouldn't be much of a "map" then, would it? Sure it would. There's nothing that requires associative containers to have search times better than O(n). It just happens that both std::map and QMap implements them at O(log n). > I see OrderedMap > similar to a QMap, just with a different key ordering scheme. So in that > way, constant time lookups would be _must_ I would say (although QMap > lookups log(n) time). It is after all a key-value store. No, sorry, I won't accept that container in Qt. -- 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
Re: [Development] implicit sharing and iterators in qt containers
> > > I'd expect to be able to use keys that do not define qHash or qLess. > Why? > > Search would be O(n). So be it. > Well it wouldn't be much of a "map" then, would it? I see OrderedMap similar to a QMap, just with a different key ordering scheme. So in that way, constant time lookups would be _must_ I would say (although QMap lookups log(n) time). It is after all a key-value store. -mandeep > > -- > 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] implicit sharing and iterators in qt containers
Mandeep Sandhu wrote: > For implicit sharing, I'll have to this instead when a non-const function > is called for the first time on the copy. This will cause a penalty when > calling such a function as the hash has to be repopulated with all entries > (eg: calling remove on the copy will take linear time instead of constant, > although subsequent calls will have no penalty). Still thinking about it. Well, that's the Qt way: to avoid copying until you really have to. The unshared container you currently have is not very idiomatic Qt. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] implicit sharing and iterators in qt containers
On segunda-feira, 31 de julho de 2017 13:36:49 PDT Mandeep Sandhu wrote: > > Maybe. I don't know how many would use it and whether it's worth spending > > our > > development time on it, though. > > It might be useful to a lazy programmer though, who doesn't want to > implement it on his/her own :) > It's not really a fundamental container itself, but rather uses a QHash & > QLinkedList to do the job. So it's not something that people can't The fact that you're using QHash makes it uninteresting. I'd expect to be able to use keys that do not define qHash or qLess. Search would be O(n). So be it. -- 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
Re: [Development] implicit sharing and iterators in qt containers
> > > Maybe. I don't know how many would use it and whether it's worth spending > our > development time on it, though. > It might be useful to a lazy programmer though, who doesn't want to implement it on his/her own :) It's not really a fundamental container itself, but rather uses a QHash & QLinkedList to do the job. So it's not something that people can't implement on their own. It's just that a a proper Qt container will have have some of the more useful bells & whistles like a lean and consistent API, iterators & implicit sharing (again something that the lazy programmer wouldn't be too inclined to do). I'll tidy things up in my private repo and make it as complete-as-possible for inclusion. I'll start a separate thread after I'm done, to discuss here if such a container is warranted for inclusion or not. Thanks, -mandeep > -- > 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] implicit sharing and iterators in qt containers
On segunda-feira, 31 de julho de 2017 11:59:54 PDT Mandeep Sandhu wrote: > On Mon, Jul 31, 2017 at 11:23 AM, Thiago Macieira > wrote: > > > > On segunda-feira, 31 de julho de 2017 11:20:43 PDT Matthew Woehlke wrote: > > > (p.s. This thread should probably be on inter...@qt-project.org...) > > > > Unless you're planning to submit this code to Qt itself, in which case you > > have to implement the implicit sharing as Qt requires. > > Would there be any interest in incorporating such functionality in the > existing container classes - i.e a map which maintains keys in insertion > (and access) order? Maybe. I don't know how many would use it and whether it's worth spending our development time on it, though. -- 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
Re: [Development] implicit sharing and iterators in qt containers
On Mon, Jul 31, 2017 at 11:23 AM, Thiago Macieira wrote: > On segunda-feira, 31 de julho de 2017 11:20:43 PDT Matthew Woehlke wrote: > > (p.s. This thread should probably be on inter...@qt-project.org...) > > Unless you're planning to submit this code to Qt itself, in which case you > have to implement the implicit sharing as Qt requires. > Would there be any interest in incorporating such functionality in the existing container classes - i.e a map which maintains keys in insertion (and access) order? This container is similar to Python's "OrderedDict". -mandeep > > -- > 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] implicit sharing and iterators in qt containers
> > > So... right now your copy ctor is O(N) and remove is O(1), correct? > Yes. > Implicit sharing makes your copy ctor O(1) and detach() O(N). IOW, > you've just deferred the copy cost until a non-const method is called. > That's basically what COW does... > Yes I understand that. And people will probably be expecting that (COW) since my container is based on other Qt containers. Thanks for your input. -mandeep > (p.s. This thread should probably be on inter...@qt-project.org...) > > -- > Matthew > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] implicit sharing and iterators in qt containers
On segunda-feira, 31 de julho de 2017 11:20:43 PDT Matthew Woehlke wrote: > (p.s. This thread should probably be on inter...@qt-project.org...) Unless you're planning to submit this code to Qt itself, in which case you have to implement the implicit sharing as Qt requires. -- 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
Re: [Development] implicit sharing and iterators in qt containers
On 2017-07-31 13:11, Mandeep Sandhu wrote: > Right now, I'm detaching the linked list during copy-construction (and > assignment). Detaching here means re-populating the LL with same entries > and then storing the new LL iterator's in the hash. > > For implicit sharing, I'll have to this instead when a non-const function > is called for the first time on the copy. This will cause a penalty when > calling such a function as the hash has to be repopulated with all entries > (eg: calling remove on the copy will take linear time instead of constant, > although subsequent calls will have no penalty). Still thinking about it. So... right now your copy ctor is O(N) and remove is O(1), correct? Implicit sharing makes your copy ctor O(1) and detach() O(N). IOW, you've just deferred the copy cost until a non-const method is called. That's basically what COW does... (p.s. This thread should probably be on inter...@qt-project.org...) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] implicit sharing and iterators in qt containers
> > > Your OrderedMap should itself be implicitly shared and clone the linked > list > on detach. > Right now, I'm detaching the linked list during copy-construction (and assignment). Detaching here means re-populating the LL with same entries and then storing the new LL iterator's in the hash. For implicit sharing, I'll have to this instead when a non-const function is called for the first time on the copy. This will cause a penalty when calling such a function as the hash has to be repopulated with all entries (eg: calling remove on the copy will take linear time instead of constant, although subsequent calls will have no penalty). Still thinking about it. Thanks for your input. -mandeep > Kevin Kofler > > ___ > 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] ChangeLog entries and reverted commits
On Monday, 31 July 2017 00:07:35 PDT Joerg Bornemann wrote: > Suppose you create a new feature in commit A for Qt 5.x. The commit > message has a change log entry. After a while A has to be reverted. You > won't have time to fix the issue properly for 5.x. The git history for > 5.x still contains the change log entry - now erronously. > > Is the script that creates change logs from git commit history aware of > reverts and filters out such entries? The human editor of the changelog is. -- 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
Re: [Development] Coin infrastructure changes
On mandag 31. juli 2017 13.24.57 CEST Laszlo Agocs wrote: > Hi, > > Are we sure that the week before the 5.10 feature freeze date is really the > best time to do this? > > Cheers, > Laszlo > Hi, Well, it is not the worst either. Currently, the integration count is quite low, but the most important thing is that it will be easy to rollback, in case of a major problem. So please report if you encounter such. For the first few hours or maybe even days we can switch between different systems in few minutes, without any additional costs. Our stress tests show that the new system is slightly more powerful and stable then existing one, so it should be easier to get changes in. Of course there is a risk, switching hardware and virtualization layer may cause some problems, but we hope that it will be transparent for you. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog entries and reverted commits
On Mon, Jul 31, 2017 at 09:07:35AM +0200, Jörg Bornemann wrote: > Suppose you create a new feature in commit A for Qt 5.x. The commit > message has a change log entry. After a while A has to be reverted. You > won't have time to fix the issue properly for 5.x. The git history for > 5.x still contains the change log entry - now erronously. > good revert commit messages add a retraction changelog entry. consequently, the re-application should then mention that fact as well, to not confuse the editor (just like the summary should mention that it's a re-application, to not confuse the readers of the log). > Is the script that creates change logs from git commit history aware of > reverts and filters out such entries? > we could do that, but that needs to happen atomically with a change of actual practice (cf. your change where neither the revert nor the re-application have a changelog). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Coin infrastructure changes
Hi, Are we sure that the week before the 5.10 feature freeze date is really the best time to do this? Cheers, Laszlo -Original Message- From: Development [mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of Frederik Gladhorn Sent: mandag 31. juli 2017 15.19 To: development@qt-project.org Subject: [Development] Coin infrastructure changes Hi all, this is mostly for your information. On Wednesday this week (most likely) we're making changes to Coin, potentially leading to some interruptions in integrations. The longer version: We've been working towards replacing the underlying virtualization layer in our Continuous Integration infrastructure and have now reached a point where we're ready (as ready as we'll get at least) to switch over from VSphere to OpenNebula. There are a bunch of advantages (not least that we can actually debug issues in OpenNebula/KVM, it'll make the scheduling code in Coin easier, ...). This will also be the point at which we start to use some of the new hardware that The Qt Company has been purchasing and getting ready, so things will initially be at the same speed and eventually much faster. We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some merges, hopefully we'll get it working really soon now. Hopefully the process is: stop the system; change branch; restart and things will work. I would expect some hickups when we scale up and run in production mode, so bear with us and report issues, we'll eventually be better off, once things are in shape. Cheers, Frederik ___ 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] Coin infrastructure changes
Hi all, this is mostly for your information. On Wednesday this week (most likely) we're making changes to Coin, potentially leading to some interruptions in integrations. The longer version: We've been working towards replacing the underlying virtualization layer in our Continuous Integration infrastructure and have now reached a point where we're ready (as ready as we'll get at least) to switch over from VSphere to OpenNebula. There are a bunch of advantages (not least that we can actually debug issues in OpenNebula/KVM, it'll make the scheduling code in Coin easier, ...). This will also be the point at which we start to use some of the new hardware that The Qt Company has been purchasing and getting ready, so things will initially be at the same speed and eventually much faster. We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some merges, hopefully we'll get it working really soon now. Hopefully the process is: stop the system; change branch; restart and things will work. I would expect some hickups when we scale up and run in production mode, so bear with us and report issues, we'll eventually be better off, once things are in shape. Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [BB++] 5 minutes long documentary
On 07/31/2017 07:12 AM, Phil Bouchard via Boost wrote: On 07/30/2017 04:54 PM, Phil Bouchard via Boost wrote: Like I promised, here's a 5 minutes long documentary on BB++: https://youtu.be/vXmddU_FS30 FAQ: "I will create a better and longer presentation this week but the goal of the language is to solve all possible memory leaks by grouping all pointers into sets which get destroyed at the end of a scope. Thus at the end of a scope, all pointers are guaranteed to be destroyed, cyclic or not. Furthermore It replaces Node.JS but uses the power of C++ for inheritance (multiple inheritance, virtual inheritance, etc.). Lastly I am not sure how the memory consumption can be increased by 2500% [in the Microsoft tests] because sizeof(boost::shared_ptr) == sizeof(void *) * 2 and so is sizeof(boost::node_ptr) == sizeof(void *) * 2." 3...2...1... Ok I'm outta here. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog entries and reverted commits
On Mon, 31 Jul 2017 11:11:41 +0200 Friedemann Kleint wrote: > have a look at https://codereview.qt-project.org/#/c/201164/ for the > Perl script. Are the two scripts competing or do they complement each other in some way? Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog entries and reverted commits
Hi, have a look at https://codereview.qt-project.org/#/c/201164/ for the Perl script. Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] implicit sharing and iterators in qt containers
Mandeep Sandhu wrote: > However, due to the issue with implicit sharing & iterators, it's not > possible for a trivial assignment operator & copy c'tor. Is there any way > around it other than making a item-by-item copy of the linked list? Your OrderedMap should itself be implicitly shared and clone the linked list on detach. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLog entries and reverted commits
Joerg Bornemann (31 July 2017 09:07) > Suppose you create a new feature in commit A for Qt 5.x. The commit > message has a change log entry. After a while A has to be > reverted. You won't have time to fix the issue properly for 5.x. The > git history for 5.x still contains the change log entry - now > erronously. > > Is the script that creates change logs from git commit history aware > of reverts and filters out such entries? Good question. I don't actually know how we generate our change-logs, but qtqa/src/createchangelog/main.go looks suspiciously likely to be it. Its extractChangeLog() appears to be parsing out the ChangeLog; its caller, appMain(), appears to be taking the full list of commits and scanning each; and the word "revert" never appears. So I consider it likely that the script doesn't take reverts into account. Talk to Simon Hausmann, he's the author, Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] ChangeLog entries and reverted commits
Suppose you create a new feature in commit A for Qt 5.x. The commit message has a change log entry. After a while A has to be reverted. You won't have time to fix the issue properly for 5.x. The git history for 5.x still contains the change log entry - now erronously. Is the script that creates change logs from git commit history aware of reverts and filters out such entries? BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
