On 11/08/2017 08:59 AM, Michael Ströder wrote:
1. The guidelines are too blurry to let two packagers
produce similar results. Adding more rules to the guidelines won't help
and make things rather worse.
That's on purpose. You are suppose to make a decision what is important
for users of your package, and what is not important. If two packagers
could independently create similar or the same results, then the process
could just be automated anyway.
2. The guide lines encourage to add _incomplete_
.changes. A "user" reading .changes won't be able to determine whether
there's enough information in there.
The point of .changes is to list important changes for the users of your
package. It's subjective because it's meant to be fed into a human
brain, not into another computer ;)
Upstream changes could include things like "refactored module", but
that's probably not important to the users of the package. It doesn't
tell your users anything more than "new upstream version" anyway.
IMO it's much better to inform the user just
about the upstream version
without any upstream changes information. This indicates that he has to
look somewhere else to get detailed information about causes of problems
he might run into.
- sssd provides a section "Highlights" in its change log. Fine. I
usually simply copy&paste that to sssd.changes. But it's already quite
lengthy and it might not be important for a "user" trying to track down
issues in his *existing* deployment. This user needs information about
If something is broken by upstream update, then the user should file a
bug report. I don't think we are expecting users to bisect upstream git
repositories so they can feed us patches?
As for "Highlights" section, I often do similar things for Boost or
NodeJS, but even then I cut it down to only include changes that are
important for openSUSE users, and I remove unrelated things like
upstream's acknowledgments or upstream bug reports or commits hashes.
Generally, you should not have more than 1 page of .changes describing
upstream version update. But having more than 1 line is generally very
So describe upstream changes in something between maybe 5 and 50 lines?
Like Executive Summary of business Financial Statements. Or like back of
the book summary for a novel. Just because space is at premium, don't
just throw up your hands and say "meh, can't list everything so let's
3. Following your explanation above almost always will
produce too many
lines added to .changes.
Therefore I consider the guidelines to be harmful, leading to false
information missing the goals.
So my suggestion is to just mention:
1. upstream release
2. packaging changes
3. security fixes / CVE numbers to make some automated compliance
CVE numbers is not just to make compliance checkers happy. *Users* are
actually looking for these too!
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org