Adam Majer wrote:
On 10/16/2017 11:10 AM, Michael Ströder wrote:
1. just mention upstream release and packaging changes
xor
2. add the complete changelog.
Sometimes the only change in version update is an entry in .changes file and upstream tarball update. Sometimes it's a little more. But in both cases the correct way to manage the .changes changelog is to put in important changes for openSUSE users in there.
If you only mention packages changes and no upstream changes, then users don't know what improvements happened, if any. Upstream changes could include security fixes, CVE numbers and other things that are important to track.
Ideally, the .changes files should capture all the important changes upstream has done in the release. As to what is important, that's for you to filter. *Read* upstream changelog and decide. But in every release, try to find something in addition to "New upstream version X.Y.Z" and include that in the .changes. If nothing else, it at least makes your package look well maintained ;)
Actually you're trying to explain the guidelines by mainly repeating them. I appreciate you taking your time to do so. IMHO I already carefully read the guide-lines and IMO I understood them and also the good intentions behind them. But I have some strong doubts. I even consider the guidelines to be harmful: 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. 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. 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 e.g. a Python module like psutil announces specific changes for non-Linux platforms this might cause a regression on Linux platforms. Having the information about the change would possibly ring a bell. 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 Ciao, Michael.