Hello! I would like to discuss here one aspect of our changelog policy. Unlike other distributions, we have an unusual rule for our RPM changelogs (.changes file): when updating to the new version, we must process an upstream changelog and copy the most important things to RPM changelog. I would like to discuss this policy and its problems and benefits. When this policy became effective, I have heard about two reasons for doing it: 1. Maintainer who does the update is aware of the changes in upstream. 2. We have easily accessible information about upstream changes. As for the first plus, yes: Maintainer is really pretty well aware of all the information because he not only reads the changelog, but he also spents a great amount of time copying it, pasting it, trying to shrink it as most as possible, reformatting it and so one. I do not want to speak for other packagers (their stories might follow), but I have spent countless hours tweaking my scripts for automagical processing the changelogs and although it saved me loads of time, it is the only thing I regularly have to fix manually during my otherwise automatical perl module updates. It is boring and IMHO completely useless work that costs us lots of time that we could spend on hacking something useful. As for the second plus, I am not aware that anyone uses this information. AFAIK we have no tool to present it to our users in a neat way. It is even not a part of the package metadata, so if you want to get it, you must get the complete package - and if you got the package, you can equally easily see upstream changelog with the same information, that you could get from the changelog. Sure, you might say that we should use RPM changelogs just for the most important changes to save our users time of searching for them. But a brief look at our packages shows that we are not doing it and usually we even cannot do it - how to pick up the most important changes from 30 minor bugfixes? How to pick them from a loads of new features in a new major version? We can either duplicate the changelog (usually unfeasible) or randomly pick up some news (this is my most usual choice) to make our policy happy. In fact, when you are interested in upstream changes, in almost every case it is more useful to take a look to upstream changelog because it is complete and better structured. When you are interested in specfile changes instead, you cannot just read them, you have to skip tons of useless information from upstream changelog - in fact, even when there is no upstream changelog, it would be better to maintain some as a patch than to pollute RPM changelog with a noise. I think that we spent countless hours of time working on something that no one is interested in. Even its very presence might be annoying in some cases. Should we really continue doing it? Would not be better to just go back several years and start to do it like others do it? Reference: http://en.opensuse.org/SUSE_Package_Conventions/Changelogs#11.4_Sourcecode_c... Anicka -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org