On 11/08/2017 08:59 AM, Michael Ströder wrote:
1. The guidelines are too blurry to let two packagers independently 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_ information to .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. Examples: - 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 *all* changes.
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 desirable too. 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 not bother".
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 checkers happy
CVE numbers is not just to make compliance checkers happy. *Users* are actually looking for these too! - Adam -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org