Moin, On Nov 08, 17 08:59:25 +0100, Michael Ströder wrote: [....]
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.
Well, I think there are advantages as wella s disadvantages in the way the .changes are created, that's clear. The bad thing is - those differe depending on which group of audience you look into. And given that we ship the packages in various places and distributions, it's no teven possible to say "that's the audience we want it for". It's always a compromise - or the lesser evil. I _personally_ hate the tendency of some upstream projects to not bobther with changes any more, but just say "use gitlogs". But I am an old-fashioned guy used to good .changes files from upstream :) Businesswise, for the Enterprise releases, the changes-files are extremely important, from a customer perspective as well as from a release manager perspective. Not knowing all packages by heart, it's often the first source of information "should/need we to take this?". And no, going to the webpages/gitlogs/otherstorage of upstream for each package is not want any one would want... A good changelog explains to me also, besides what you mentioned, changes in behavior, incompatibilities, and gives me a rough outline why I would want this. Stefan -- Stefan Behlert, SUSE LINUX Release Manager Enterprise Server Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org