Please review sources

Check script succeeded

Being evaluated by staging project "openSUSE:Factory:Staging:adi:1"

Picked "openSUSE:Factory:Staging:adi:1"

The legal review is accepted preliminary. The package may require actions later on.

1200 lines of changelog - which is essentially a git commit log.

Please improve:

Then, assort what you have found with due care:

Don't just copy what you find without reviewing yourself.
Avoid and trim anything related to the build procedure of the package if it has no visible effect on the user. The software is already built by the time it reaches the user.
Like with summaries, remove anything about non-openSUSE platforms.
You can use SCM commit messages, if they prove to be useful. If in doubt, don't.
Now, can you, as a package maintainer, make sense of every news item? Does the item mean something to you? If not, then neither does it for the user, and the item in question should be dropped.
If, at this point, there is nothing to report, say so and consider it done. (E.g. “* No user-visible changes” when, for example, upstream only changed the way the software is built.)
Be concise. Pick only the topmost interesting points: If you have over 30 lines of changelog, it is time to stop and refer the user to the other materials (such as upstream-provided news files, web links, …)
Be concise (part 2). Summarize and generalize the points: Don't go too much into specifics of a modification — a suitably interested user can look for implementation details elsewhere.
If there is an incompatible change that requires the user to adapt their configuration and/or setup, this should be mentioned in the changelog of the package, too, to make the users aware of it.

1200 lines of changelog - which is essentially a git commit log.

Please improve:

Then, assort what you have found with due care:

Don't just copy what you find without reviewing yourself.
Avoid and trim anything related to the build procedure of the package if it has no visible effect on the user. The software is already built by the time it reaches the user.
Like with summaries, remove anything about non-openSUSE platforms.
You can use SCM commit messages, if they prove to be useful. If in doubt, don't.
Now, can you, as a package maintainer, make sense of every news item? Does the item mean something to you? If not, then neither does it for the user, and the item in question should be dropped.
If, at this point, there is nothing to report, say so and consider it done. (E.g. “* No user-visible changes” when, for example, upstream only changed the way the software is built.)
Be concise. Pick only the topmost interesting points: If you have over 30 lines of changelog, it is time to stop and refer the user to the other materials (such as upstream-provided news files, web links, …)
Be concise (part 2). Summarize and generalize the points: Don't go too much into specifics of a modification — a suitably interested user can look for implementation details elsewhere.
If there is an incompatible change that requires the user to adapt their configuration and/or setup, this should be mentioned in the changelog of the package, too, to make the users aware of it.

Reopened via staging workflow.

Being evaluated by group "factory-staging"

Unstaged from project "openSUSE:Factory:Staging:adi:1"

Declined via staging workflow.

superseded by 934543