Port a lot of foreach/FOREACH (still 220 items)
It will be deprecated in qt6.
NO_CHANGELOG
dfaure |
Port a lot of foreach/FOREACH (still 220 items)
It will be deprecated in qt6.
NO_CHANGELOG
autotest ok
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
"Make to compile without foreach"
it's missing words or some have to be changed.
The summary also lacks explanations *why* this change is needed (like almost *all* the commits in the pim repositories)
we're not using SVN anymore where a commit had to be pushed before preparing the next one, there's time to explain things.
cgiboudeaux: the Qt documentation says that foreach is deprecated, what do you suggest Laurent should add to the commit log? Just "it's deprecated", a copy/paste of the Qt docu, or https://www.kdab.com/goodbye-q_foreach/ ?
autotests/globaltest.cpp | ||
---|---|---|
110 | qAsConst? I guess QFETCH doesn't make the variables const. | |
src/widgets/kdirmodel.cpp | ||
263 | qAsConst |
"It will be deprecated in Qt6" tells packagers why this commit is done.
In a perfect world, developers would write changelog files with changes worth mentioning when packagers prepare the updates.
As this is not close to happen, we extract git logs and spend an insane amount of time cleaning meaningless commit messages for *each* released tarball (and specially the pim ones) and we repeat that for *every* release.
Yep, but extracting changelogs from commit logs can be mostly automated, including filtering out many commits with the same first line.
It's what I do in git@git.kde.org:sysadmin/release-tools branch frameworks/5.0 file parse_changelogs.pl.
But yeah, if people could add NO_CHANGELOG somewhere in the commit log it would make this easier. Laurent, can you do that for mechanical commits such as this one?
"But yeah, if people could add NO_CHANGELOG somewhere in the commit log it would make this easier. Laurent, can you do that for mechanical commits such as this one?"
no problem for adding [NO_CHANGELOG] in commit message
FYI NO_CHANGELOG doesn't have to be in the first line (which would make noise in phab review titles for new requests, etc). It can be a line of its own, for example towards the end of the commit log.
Thanks!
GIT_SILENT is "trivial, don't look at the commit" -- at least it used to be. Not really applicable to commits such as this one....
hmmmm, ok, i don't know why we wouldn't want things like this to now show in the autogenerated changelog, but ok, your call :)
I view the KF5 changelog as the list of things that can be useful to the users of the frameworks (i.e. application developers).
When we add API, fix a bug, or change dependencies, that's useful for them to know.
When we repair a unittest, fix typos in comments, port away from deprecated methods and so on, I don't see how that is useful for the application developers to know. To me it would just be noise in the changelog, it doesn't affect them.
Sure, in the long run it means we're maintaining the stuff and making sure it will still work with future versions of Qt, but they'll get notified of that when the time comes anyway.
Do we understand all possible regressions that this can cause? If yes, where are they documented so that we can verify? See bug 406426.
Yes, the pitfalls are well known.
and for performance reasons, "don't use range-for over a non-const container", but that's of course not as bad as 1) and 2) which lead to crashes.
https://www.kdab.com/goodbye-q_foreach/ has a lot of details on point 2) in the comments.
@mlaurent Hi, sorry to default to you here, but given the risks with foreach porting (I have done my own share of mistakes in such despite all concentration :) ) https://bugs.kde.org/show_bug.cgi?id=408801 might be triggered by one of this here, have not yet investigated more.
With your mind perhaps still with memories about the code from the foreach porting work, could you given that bug take a look where this might be due to containers being modified in a range-for loop?