@cv3d, thank you for the patch! It looks like it's quite big patch that touches many files. Can you first submit the patch where non-core stuff is changed, like AGAST, AKAZE, DrawMatches flags? And then move to the core stuff (or maybe even leave the core stuff as-is for now).

@vpisarev Thank you very much. Here is a less-offensive version of the project.

@alalek @vpisarev In the meanwhile, how about merging this PR?

@alalek I also utilized CV_UNUSED macro recently to unify the coding style.
I can open a separate PR for it if you find it too distracting here..

CV_UNUSED() is a trivial change. As you wish.

Oops! I was inpatient, and I just removed it..

I can try to recover commits from build machines. Are they needed?

Actually you can get then from your local machine (if git gc does not run):

git branch recover  <commit-hash>

Commit hash is available in "builder" properties.

Thanks for your concern, but it not important, and I guess it is cleaner this way.
I opened another PR for them, as they are totally unrelated PRs after all.

@alalek I assume you just forgot about this PR, but in case it is intentional, I wonder why you are delaying the merge of this PR? It does not touch core stuff or affect the user code, is it?

I didn't.
This patch is not properly tested / complete (code using these changes are in another place).
There is still "odr" problem with enums from type-traits (need to remove "const reference" and use just "const").

not properly tested / complete

@alalek What do you suggest then?

There is still "odr" problem with enums from type-traits

I believe I just fixed that. Can you please revise again?

@cv3d, thank you! @alalek, thank you for the detailed review. Let's merge it in! We may still rename some of the long type names later, but for now it's fine. 👍

@alalek Lastly merged two commits are actually 23 independent commits...
You know the number of commits is the only salary/prize I receive from this project, and you lose nothing in exchange! I wonder if shall I make a separate PR for each commit to avoid this in future...

I checked the contributors list thinking I ranked up, but it seems you squashed all the commits together, despite that they are totally independent from each other 😕

P.S. I even wrote allow_multiple_commits=1 in the description, but it got removed... This is very disappointing!

This PR has 21 complete commits with 567 added lines.
These commits are squashed due current policy rules of project maintenance.

• we don't test each intermediate commit. We test only final merged commit.
• number of commits in this repository is about 25k
• repository growing quickly (100-200 per month), so we attempt reducing number of incoming commits.
• whole history doesn't help to maintain project

if shall I make a separate

Consider calculation of commits from GitHub PR instead from squashed commit from repository.
Squashing of them is just a technical step.

However, I believe, that number of commits / changed lines is not a valid or robust SoW.

P.S.
I'm often using git blame to determine regressions:

• it is usually not fully automated process
• 3-6 min per single build + manual build validation.
• huge number of commits is a real pain.
• non-green commits with broken builds is a triple pain, because the next step is "skip: i+1" instead of bisection (N / 2).
• squashed commit is not a problem: GitHub stores PR history too, it can be extracted like this:

git fetch upstream +pull/12310/head:pr12310

I understand the pain in debugging, and what is done is done!
I just wished you would give it another thought considering the effort, or at least confirm if I do not mind.

@alalek Because I received some comments here, I just read your reply again, and I cannot resist to ask you...

that number of commits / changed lines is not a valid or robust SoW

Then why do you rank the contributors in a descending order according to their number of commits in the changes log? My contribution here would be equivalent to some spelling correction in the documentation, no? BTW: Do you squash ALL PRs?

why do you rank the contributors in a descending order according to their number of commits

IDK who started it, we just continue using the same command for consistency. One can use Insights tab for a better view with date range, commits/additions/deletions and links to accounts.

Do you squash ALL PRs?

Usually we ask contributors to squash commits, but sometimes we do it by ourselves and sometimes we forget to do it 😞. Several commits in one PR are allowed if they represent unrelated changes, e.g. one fixes an issue, another formats the code, or when there are several commits by different authors, e.g. one person implements a big feature, another makes minor fixes.

we just continue using the same command for consistency

If you are able to change the squash policy, then I believe you can change the change log as well.

Anyway, I wish you would understand my stand point.
From now on, in hope to avoid that a contribution would appear in the change log as equivalent to a minor documentation fixup, I am starting to ask for explicit attribution in case you want to utilize a contribution of mine fully or partially, such as in #12611.

Several commits in one PR are allowed if they represent unrelated changes

I would understand if they were related, but that was not the case. In fact, each commit was totally unrelated, and addresses different enums, mostly in different modules.

This PR has been merged after 4.0-alpha, that is why it is not mentioned in the changelog. We try to mention all big features in the manually written part of the log and this one will be covered in the next release. Or what do you mean by "properly attribute"?

You can also propose an update to our site if you think we missed something important: https://github.com/opencv-infrastructure/opencv.org (we will propagate it to wiki/Changelog if necessary).

We try to mention all big features in the manually written part of the log

I know, it comes usually in the form: "we introduced new blah blah", and after that comes names and numbers besides them, instead of their respective, meaningful contributions, if any.

properly attribute

Not only papers should be referenced, but also individuals/entities who implemented them, or made meaningful improvements to them. Personally, I know who wrote several papers implemented here, but I have no clue who implemented it, and I do not find any documentation to locate them, except to look in the source code. As you might know, in open source societies, although they allow it under the licence of the software, everyone owns his own contribution, unless they transfer their ownership as well (it is not the case in OpenCV). Therefore, contributors have the right to be mentioned, especially if they ask for an explicit attribution, given that OpenCV respects others rights!

I expect OpenCV website/documentation to mention the contribution, and its corresponding contributors - at least the main ones, hopefully in a table, like this:

And in case the feature is mentioned in other places (e.g. documentations or publications), it should appear in something like: "feature2 (implemented by author1, author2 [link for further information - perhaps the approperate entry in the changes log])".

@cv3d , please propose a PR to the website: https://github.com/opencv-infrastructure/opencv.org so that we can discuss it there.

If you want detailed changes, consider using this:

• https://github.com/opencv/opencv/pulls?q=is%3Apr+is%3Aclosed (there is "feature" label)
• git log
• git blame
• other online/offline tools to analyze changes.

All these tools provides objective information "as is".

Any changelog "notes" is a kind of subjective information (from changelog writer). There is no goal to put all things here. Most part of OpenCV users don't use more that 20% of available OpenCV functionality - so such detailed reports are just useless mess for them.

Anyway, currently we don't have free resources to maintain separately high quality change logs. Also there are no well defined policies/processes for that.

Therefore, contributors have the right to be mentioned, especially if they ask for an explicit attribution, given that OpenCV respects others rights

It is already here, see git log. Using OpenCV contributions with promotion goals should be avoided.

I do not find any documentation to locate them, except to look in the source code

Is source code open? Is code history available? Are you able to find PR from the source code line?
Suggest authors of these patches to add this information into PRs descriptions at least. Updates are not prohibited by project.
"Documentation" has one big problem - it becomes outdated quickly, and it is often without information about modification date or further updates. Also it is not an "original source" anyway.

P.S. KPI, based on commits number / changed lines only. doesn't look as a professional approach.

baseline: It is a mess to mention a contribution without its contributor in the same context. How come mentioning the contributor below some active spelling checker be enough of a recognition?
You can say open source and everything, but git log is for the geeks, while normal people utilize browsers to fetch data (normally via documentation - not github labels).

If I were you I would not deem someone asking for basic right of effort recognition, as if he is asking for promotion... Anyway, if you think a contribution if made for promotion, then do not merge the efforts. Alternatively, consider writing proper change log or at least ask contributors to sign a copyright assignment agreement in advance, so that you can say "we introduced" without any guilt.. That is it!

@alalek @mshabunin How about something like this? It is generated automatically, thus objective, for the 3.4.2..3.4.3 release as an example. Download from here!

Hopefully, you would also consider automating the process of rewriting the change log for older releases as well.

Feature Introducers

Bug Fixers: Alexander Alekhin (20), Dmitry Kurtaev (9), berak (7), Maksim Shabunin (4), csukuangfj (2), Tomoaki Teshima (2), Sayed Adel (2), Vitaly Tuzov (1), Li, Peng (1), Nesterov Alexander (1), tyl12 (1), Triplesalt (1), Steven Miao (1), maver1 (1), zarelaky (1), gdemarcq (1), Lucas Teixeira (1), Hiro Kobayashi (1), Suleyman TURKMEN (1), Bahram Dahi (1), Rostislav Vasilikhin (1), doctorcolinsmith (1), logic1988 (1), Hamdi Sahloul (1), Maxim Smirnov (1)

Optimizers: Alexander Alekhin (2), Li, Peng (1), Dmitry Kurtaev (1), Vadim Pisarevsky (1), Sayed Adel (1), maver1 (1)

and several other contributors.

These lists have subjective nature.
For example, I believe, that documentation improvements should have separate section instead of mixing with new OpenCV algorithms, API features, etc. The same is for "bindings only" improvements (they are not interested for C++ only OpenCV developers).

label_attrs = [
     #     title           , label         , show_table
    ("Feature Introducers", "feature"     , True ),
    ("Bug Fixers"         , "bug"         , False),
    ("Optimizers"         , "optimization", False),
] 

@alalek It is totally configurable, and you can add as much labels as you want, as long as you add them to the PR itself.

that documentation improvements
"bindings only" improvements

Do you want me to add the category column? Perhaps it helps to show which module the contribution is for..

@cv3d , the same changelog already exists on GitHub, why should we duplicate it? Maybe we can just provide a link in the wiki changelog?

the same changelog already exists

Well, can we provide a link to the inline source code documentation, instead of generating the standalone documentation?

• Rather that just showing names and meaningless numbers, the script I gave you is a seed to make more professional change log. It can be developed further to provide sophisticated and rich report.
• Github is too much of clutter for a summary. Summary reports, and reports in general, are irreplaceable by raw data.
• You want to regenerate for several reasons:
  • To show the contributor and the contribution in the same context, rather than beating around the bush
  • To group, order, and prioritize (by significance, module, user, etc)
  • To edit the titles of the contributions, if needed
  • To excluding specific PRs (e.g. merge ones)

should have separate section

I guess organizing the contributions by type first, and by name second, is the best way to go.
However, for the time being I did the opposite 😕 (see the updated comment)
Anyway, consider giving it a try!