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
On Feb 24, 09 16:55:27 +0100, anicka@suse.cz wrote:
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.
$ rpm -q --changelog is a useful tool for *really* comparing packages. Often the pakage version number is unchanged, but an important patch was added. In this case, our changelog is the only source of information.
For version updates, the full upstream changelog is relevant. Shortening to a 10 line excerpt may cut away the one bit of information that a user wanted to know.
I'd suggest to allow a URL-reference to the upstream changelog as replacement for the excerpt.
cheers, JW-
On Tue, 24 Feb 2009, Juergen Weigert wrote:
On Feb 24, 09 16:55:27 +0100, anicka@suse.cz wrote:
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.
I completely agree with Anicka.
$ rpm -q --changelog is a useful tool for *really* comparing packages. Often the pakage version number is unchanged, but an important patch was added. In this case, our changelog is the only source of information.
For version updates, the full upstream changelog is relevant. Shortening to a 10 line excerpt may cut away the one bit of information that a user wanted to know.
I'd suggest to allow a URL-reference to the upstream changelog as replacement for the excerpt.
I don't agree with you at all. In the rpm changelog 'Update to new upstream version 1.2.3' is short and enough. If a packager adds local patches this needs to be (and is) mentioned in the rpm changelog.
What I would like to see (and I see we are atm pretty bad at it) is to enforce a basic set of documentation for each package that is put in /usr/share/doc/packages/$NAME. In this place there belongs 1) license information (for legal reasons even), 2) upstream provided README / NEWS / ChangeLog (which one of those are relevant or even useful varies heavily from package to package, so it's up to the maintainer to choose). 3) if there is SUSE specific modifications, like configuration changes, there should be a README.SUSE file.
rpm -q --changelog is absolutely not a convenient place for such information.
Richard.
On Feb 24, 09 17:28:53 +0100, Richard Guenther wrote:
On Tue, 24 Feb 2009, Juergen Weigert wrote:
On Feb 24, 09 16:55:27 +0100, anicka@suse.cz wrote:
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.
I completely agree with Anicka.
$ rpm -q --changelog is a useful tool for *really* comparing packages. Often the pakage version number is unchanged, but an important patch was added. In this case, our changelog is the only source of information.
For version updates, the full upstream changelog is relevant. Shortening to a 10 line excerpt may cut away the one bit of information that a user wanted to know.
I'd suggest to allow a URL-reference to the upstream changelog as replacement for the excerpt.
I don't agree with you at all. In the rpm changelog 'Update to new upstream version 1.2.3' is short and enough. If a packager adds local patches this needs to be (and is) mentioned in the rpm changelog.
I did not mean to say that the full upstream changelog should be in our changelog. My point is that an excerpt is dubious, as it is both too noisy and too crippled. If we can agree that simply stating the version-number is good enough, fine with me. Although a pointer to upstream would still be no harm.
What I would like to see (and I see we are atm pretty bad at it) is to enforce a basic set of documentation for each package that is put in /usr/share/doc/packages/$NAME. In this place there belongs 1) license information (for legal reasons even), 2) upstream provided README / NEWS / ChangeLog (which one of those are relevant or even useful varies heavily from package to package, so it's up to the maintainer to choose). 3) if there is SUSE specific modifications, like configuration changes, there should be a README.SUSE file.
This requires to have the package installed first. I'd like to give the user as much information as possible before he installs.
cheers, JW-
On Tue, 24 Feb 2009, Juergen Weigert wrote:
On Feb 24, 09 17:28:53 +0100, Richard Guenther wrote:
On Tue, 24 Feb 2009, Juergen Weigert wrote:
On Feb 24, 09 16:55:27 +0100, anicka@suse.cz wrote:
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.
I completely agree with Anicka.
$ rpm -q --changelog is a useful tool for *really* comparing packages. Often the pakage version number is unchanged, but an important patch was added. In this case, our changelog is the only source of information.
For version updates, the full upstream changelog is relevant. Shortening to a 10 line excerpt may cut away the one bit of information that a user wanted to know.
I'd suggest to allow a URL-reference to the upstream changelog as replacement for the excerpt.
I don't agree with you at all. In the rpm changelog 'Update to new upstream version 1.2.3' is short and enough. If a packager adds local patches this needs to be (and is) mentioned in the rpm changelog.
I did not mean to say that the full upstream changelog should be in our changelog. My point is that an excerpt is dubious, as it is both too noisy and too crippled. If we can agree that simply stating the version-number is good enough, fine with me. Although a pointer to upstream would still be no harm.
What I would like to see (and I see we are atm pretty bad at it) is to enforce a basic set of documentation for each package that is put in /usr/share/doc/packages/$NAME. In this place there belongs 1) license information (for legal reasons even), 2) upstream provided README / NEWS / ChangeLog (which one of those are relevant or even useful varies heavily from package to package, so it's up to the maintainer to choose). 3) if there is SUSE specific modifications, like configuration changes, there should be a README.SUSE file.
This requires to have the package installed first. I'd like to give the user as much information as possible before he installs.
Well. I think the version number together with the package description is enough. Of course with a custom tool (zypper?) it should be easy to extract /usr/doc/packages/$NAME/$whatever and display it without installing the package. Of course you need to download it first - but this is needed for the changelog anyway.
Richard.
Juergen Weigert wrote:
I did not mean to say that the full upstream changelog should be in our changelog. My point is that an excerpt is dubious, as it is both too noisy and too crippled. If we can agree that simply stating the version-number is good enough, fine with me. Although a pointer to upstream would still be no harm.
URL is useless when you have no connectivity. Upstream changes should be packaged (ChangeLog, NEWS, etc.) and if there is none, packager could create it (and copy the changes from website or so, but these cases are rare). If we will follow that, it would suffice to put this into our changes:
- updated to 1.2.3 (see NEWS)
This requires to have the package installed first. I'd like to give the user as much information as possible before he installs.
When the package is downloaded, it really is not a big difference to do "rpm -qp --changelog pkg.rpm" or to view it contents using mc and browse for the right file. It would be good if there were changes in repository metadata BEFORE downloading the package to system, but this is not possible even now AFAIK.
URL is useless when you have no connectivity. Upstream changes should be packaged (ChangeLog, NEWS, etc.) and if there is none, packager could create it (and copy the changes from website or so, but these cases are rare). If we will follow that, it would suffice to put this into our changes:
- updated to 1.2.3 (see NEWS)
Actually, although it is much better than the thing we are doing now, just imagine how weird will it look after several updates:
... - updated to 1.2.3 (see NEWS) - updated to 1.2.2 (see NEWS) - updated to 1.2.1 (see NEWS) ...
It would be probably better to think up some standard location for a changelog and maintain it as a symlink to the proper file, without having to talk about it again and again in RPM changelog.
Even ie. zypper would have easy way to obtain this information then, if ever needed.
Anicka
anicka@suse.cz wrote:
Actually, although it is much better than the thing we are doing now, just imagine how weird will it look after several updates:
- updated to 1.2.3 (see NEWS)
- updated to 1.2.2 (see NEWS)
- updated to 1.2.1 (see NEWS)
It is not so weird when you consider the entries headers
* Tue Nov 13 2008 Pavol Rusnak prusnak@suse.cz - updated to 1.2.3 (see NEWS) * Wed Aug 14 2007 Pavol Rusnak prusnak@suse.cz - updated to 1.2.2 (see NEWS) * Sat Dec 22 2006 Pavol Rusnak prusnak@suse.cz - updated to 1.2.1 (see NEWS)
but ...
It would be probably better to think up some standard location for a changelog and maintain it as a symlink to the proper file, without having to talk about it again and again in RPM changelog.
... I agree with that. We could create symlinks from NEWS or ChangeLog to Upstream_Changes (or something like that) and later patch rpm to use this file (eg. rpm -q --upstreamchangelog pkg.rpm). We could also add macro %changes which will mark the file in filelist and create the link automatically.
There is one problem, though. Some projects have information scattered in both NEWS and ChangeLog files, but I agree that it is a problem of these projects, not distribution.
... I agree with that. We could create symlinks from NEWS or ChangeLog to Upstream_Changes (or something like that) and later patch rpm to use this file (eg. rpm -q --upstreamchangelog pkg.rpm). We could also add macro %changes which will mark the file in filelist and create the link automatically.
Yes, these features are nice to have. I do not think that patching RPM right now is a feasible option but at least the macro would be very convenient.
I would really welcome to move pur package conventions this direction.
There is one problem, though. Some projects have information scattered in both NEWS and ChangeLog files, but I agree that it is a problem of these projects, not distribution.
Sure. But usually, one is a summary of most important changes and the other something like a dump of version control system logs. The only thing we really have to do is to choose, which is more interesting and it is probably just up to maintainer.
Anicka
anicka@suse.cz wrote:
There is one problem, though. Some projects have information scattered in both NEWS and ChangeLog files, but I agree that it is a problem of these projects, not distribution.
Sure. But usually, one is a summary of most important changes and the other something like a dump of version control system logs. The only thing we really have to do is to choose, which is more interesting and it is probably just up to maintainer.
I'm aware of that of course, but I was talking about the less mature projects where some of the developers put their changes into NEWS and others into ChangeLog. These are very rare fortunately, but I've encountered them :)
On út 24. února 2009, Juergen Weigert wrote:
On Feb 24, 09 16:55:27 +0100, anicka@suse.cz wrote:
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.
$ rpm -q --changelog is a useful tool for *really* comparing packages. Often the pakage version number is unchanged, but an important patch was added. In this case, our changelog is the only source of information.
For version updates, the full upstream changelog is relevant. Shortening to a 10 line excerpt may cut away the one bit of information that a user wanted to know.
I fully agree. Shortening and re-formatting upstream changelog into .changes is not that good idea.
I'd suggest to allow a URL-reference to the upstream changelog as replacement for the excerpt.
Then the document should stay there during package lifetime. This can be guaranteed only on Novell server.
Other possibility would be to package the upstream changelog under some standard name and eventually extract it into repository metadata.
Vladimir
Am Dienstag 24 Februar 2009 schrieb anicka@suse.cz:
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?
I have to admit I was never a big fan either. And what it makes especially strange is that we allow "update to x.y" for packages where upstream does not provide NEWS.
While my job is certainly easier to go look into .changes file to see important changes that are interesting for checking, but I'm for sure not interested in a detailed upstream bug log.
And you're not the first one to complain either. What I wonder: how can make sure the maintainer _knows_ about the changes of upstream? E.g. I updated exiv2 to a new version as I fixed gcc 4.4 compilation. And I did read through the changelog, but still I didn't spot the little "[design] Publish only API objects in the installed header files." - which broke a dozen other packages.
No idea how to go forward, there are people that like it and others that don't, but it means work for almost anyone. I would shorten the policy to "important NEWS" should be listened. Then it's up to the maintainer if it "Force bytes in all the format_* methods" belongs in a rpm changelog or not. Because most users will simply shrug ;)
Greetings, Stephan
And you're not the first one to complain either. What I wonder: how can make sure the maintainer _knows_ about the changes of upstream? E.g. I updated exiv2 to a new version as I fixed gcc 4.4 compilation. And I did read through the changelog, but still I didn't spot the little "[design] Publish only API objects in the installed header files." - which broke a dozen other packages.
No change here, IMHO.
Speaking just for myself: Reading the changelog carefully has nothing in common with producing the food for our RPM changelog - when there is a ton of changes in upstream and they seem to be quite equally important, I just choose some from the beginning and voila, work is done. If I missed some catch during the actual reading, I will not pick it up during writing RPM changelog. So youd did not make sure I know about it anyway. (At least in my case, you did much worse in fact: knowing that I will have to spend lots of time moving the text here and there, I will be actually _less_ careful during reading.)
BTW, I think I would be really not to blame. It is upstream responsibility to mark backward incompatible changes so that they can be easily spotted in the changelog. They usually do it. If they do not, it is upstream bug, not my fault.
Sure, it will not help us that much when we are going to fix the problems we could avoid. But if we read the diff between two versions carefully instead of a changelog, we could avoid all the problems, not only these that upstream already found ;-)
Anicka
On st 25. února 2009, Stephan Kulow wrote:
And you're not the first one to complain either. What I wonder: how can make sure the maintainer _knows_ about the changes of upstream? E.g. I updated exiv2 to a new version as I fixed gcc 4.4 compilation. And I did read through the changelog, but still I didn't spot the little "[design] Publish only API objects in the installed header files." - which broke a dozen other packages.
Well, this concrete change was discussed on the Exiv2 mailinglist a lot. Package maintainers are already encouraged to watch upstream mailinglists.
In general, the only reliable way, how to spot such problems is to run a test build of dependent packages. The question is if it should be left up to the maintainer. Maybe we could make it part of the review process.
Vladimir
In general, the only reliable way, how to spot such problems is to run a test build of dependent packages. The question is if it should be left up to the maintainer. Maybe we could make it part of the review process.
I do not think that we (either maintainers or someone else) should put a lot of extra effort into searching for the problems that happen very seldom and that can be fixed later. We should try our best to do packaging effective, not to add layers of complexity and obstacles. I believe that fix some problem here and there requires less effort than searching for even the least probable points of failures.
I think that to believe maintainers that they are doing their best to be aware of incompatible changes, bugs, potential problems and so one is good enough. They will miss some bugs, surely, but it will happen anyway.
Anicka
Le mardi 24 février 2009, à 16:55 +0100, anicka@suse.cz a écrit :
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?
This was discussed on opensuse-gnome last month: http://lists.opensuse.org/opensuse-gnome/2009-01/msg00132.html
The main issue I have with changing this policy is when people submit an update to the devel project. Then the maintainers have to review this update, and without the changelog, it's hard to know if something is wrong in the update.
Else, yeah, I agree, it's quite time consuming and annoying.
Vincent
On Wed, 25 Feb 2009, Vincent Untz wrote:
Le mardi 24 février 2009, à 16:55 +0100, anicka@suse.cz a écrit :
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?
This was discussed on opensuse-gnome last month: http://lists.opensuse.org/opensuse-gnome/2009-01/msg00132.html
The main issue I have with changing this policy is when people submit an update to the devel project. Then the maintainers have to review this update, and without the changelog, it's hard to know if something is wrong in the update.
There's the commit message from the build-service RCS, isn't that a proper place for noting the changes?
Richard.
-- Richard Guenther rguenther@suse.de Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Le mercredi 25 février 2009, à 17:45 +0100, Richard Guenther a écrit :
On Wed, 25 Feb 2009, Vincent Untz wrote:
Le mardi 24 février 2009, à 16:55 +0100, anicka@suse.cz a écrit :
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?
This was discussed on opensuse-gnome last month: http://lists.opensuse.org/opensuse-gnome/2009-01/msg00132.html
The main issue I have with changing this policy is when people submit an update to the devel project. Then the maintainers have to review this update, and without the changelog, it's hard to know if something is wrong in the update.
There's the commit message from the build-service RCS, isn't that a proper place for noting the changes?
You misunderstood me. If the upstream tarball has a NEWS file mentioning:
+ Fixed this. + Included new great feature. + Add patch from $distro. + Drop dependency on foo. + Add optional feature depending on libawesomeness.
Then, it's possible that someone updates the package to this upstream version but forgets to drop the BuildRequires on foo, or to add the libawesomeness-devel BuildRequires. That's what I want to catch when reviewing changes.
Sure the example I gave is pretty trivial, but some NEWS file are cryptic unless you know really well this part of the stack, so it can be easy to miss one relevant change.
As a packager, I don't want to include all those details in .changes. As a reviewer, I need access to those details. (note that they don't have to be in .changes as long as I have easy access to them)
Vincent
As a packager, I don't want to include all those details in .changes. As a reviewer, I need access to those details. (note that they don't have to be in .changes as long as I have easy access to them)
If you want to do your reviewer's work that well now, you MUST read upstream changelog anyway.
Why? Because nobody promises you that the maintainer will evaluate any particular new feature as an important one - he might just list another ten (maybe even more) important changes and if you read only .changes, you might miss that one that is interesting for you.
So a standardized path to unmodified upstream changelog would enable you to do your work more easily - the point is that you should read complete upstream changelog, not an excerpt produced by someone who could miss some important change.
Anicka
Le mercredi 25 février 2009, à 18:13 +0100, anicka@suse.cz a écrit :
As a packager, I don't want to include all those details in .changes. As a reviewer, I need access to those details. (note that they don't have to be in .changes as long as I have easy access to them)
If you want to do your reviewer's work that well now, you MUST read upstream changelog anyway.
Why? Because nobody promises you that the maintainer will evaluate any particular new feature as an important one - he might just list another ten (maybe even more) important changes and if you read only .changes, you might miss that one that is interesting for you.
In GNOME:Factory, we put all the new content of NEWS in .changes. And GNOME modules are doing a relatively good job at writing an informative NEWS file. So the person who will do the update will put what needs to be put in .changes anyway. Which is why, as a reviewer of G:F, no, the upstream changelog is often not necessary.
Also, it all depends on the person who submits the update: we have a few contributor in the GNOME team who we know well, so we trust them to put the right content in .changes -- but it's always hard for non-upstream people to understand some changes. If it's some random person that submits an update, then sure, I'll check the ChangeLog/NEWS from the tarball.
Anyway, I think I'm just pointing out the fact that if we remove this information from .changes, it's important to have an easy access to it during the package review step. (which sounds possible if we provide easy access to it from rpm -q --changelog)
Vincent
On Wed, 2009-02-25 at 17:23 +0100, Vincent Untz wrote:
Le mardi 24 février 2009, à 16:55 +0100, anicka@suse.cz a écrit :
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?
This was discussed on opensuse-gnome last month: http://lists.opensuse.org/opensuse-gnome/2009-01/msg00132.html
I also brought it up on this list. Unfortuantly, I can't find the thread, but it was at the end of January this year.
Cheers, Magnus
On út 24. února 2009, anicka@suse.cz wrote:
Hello!
I would like to discuss here one aspect of our changelog policy.
What about this policy: "Backward incompatible changes should be mentioned in the RPM changelog."
This eliminates the problem with 30 equaly important bugfixes and gives clear direction what to look for, even if it is not enough emphasized by upstream.
Vladimir
Am Friday 27 February 2009 15:11:45 schrieb Vladimir Nadvornik:
On út 24. února 2009, anicka@suse.cz wrote:
Hello!
I would like to discuss here one aspect of our changelog policy.
What about this policy: "Backward incompatible changes should be mentioned in the RPM changelog."
This eliminates the problem with 30 equaly important bugfixes and gives clear direction what to look for, even if it is not enough emphasized by upstream.
Yeah. But I wonder how changes can be incompatible in another direction than backward. Just the wording, but it puzzled me.
Greetings, Stephan
On pá 27. února 2009, Stephan Kulow wrote:
Am Friday 27 February 2009 15:11:45 schrieb Vladimir Nadvornik:
On út 24. února 2009, anicka@suse.cz wrote:
Hello!
I would like to discuss here one aspect of our changelog policy.
What about this policy: "Backward incompatible changes should be mentioned in the RPM changelog."
This eliminates the problem with 30 equaly important bugfixes and gives clear direction what to look for, even if it is not enough emphasized by upstream.
Yeah. But I wonder how changes can be incompatible in another direction than backward. Just the wording, but it puzzled me.
For example an application can't parse config file writtet by newer version of that application. It is not that interesting for us and documenting it would be a lot of effort for the maintainer because it is often not mentioned anywhere.
Vladimir
On Tue, Feb 24, 2009 at 04:55:27PM +0100, anicka@suse.cz wrote:
As for the second plus, I am not aware that anyone uses this information. AFAIK
Oh YES! I'm certainly using this information all the time.
we have no tool to present it to our users in a neat way. It is even not a part
There *is* a very nice tool, "yum --changelog update", which does exactly that, and which will hopefully be doable with zypper in the future.
It is one of the things that makes it very hard for me right now to use zypper. It quickly becomes an essential feature, once you know about it. It's not a well-known feature in the openSUSE world I guess. openSUSE tools haven't got this far, and while what we call "patches" has achieved something remotely similar, it is more meant for end-user who are not interested in details though. (And who hopefully forgive the lousy texts that are presented there.)
I have a few systems these days where I evaluate zypper, and I it may sound weird but I actually run "yum --changelog update" in addition to zypper, just to see what happens, because this information is so helpful, while zypper offers me only "meaningless numbers".
I use the information to be prepared for upcoming breakage, to appreciate welcome fixes, remove workarounds possibly existing locally, and, very convenient, to judge whether a package has simply been *rebuilt* or *changed* at all.
All this is fundamental for me both in my role as developer as in my role as administrator.
(Knowing if a package has been rebuilt or changed doesn't require detail in the changelog, though, one line is enough, so it isn't actually relevant to the topic of your post.)
[...]
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.
Stupid wisdom: what's noise for you, can be information for somebody else, who is actually working with the package.
The fact that not everybody looks at the changelog doesn't mean that it's not useful for some people. So there is no need to argue about that.
Having said that, I personally don't *require* a detailed changelog. I may appreciate it very much when it's there, should I look for it, but well, that's all.
I guess if it's helpful for *yourself* as a packager in some way, make it detailed.
It certainly was helpful for myself as a packager, taking the time to go over the changelog, reformatting it, and noticing each change. It let me be well oriented about what's going on upstream and in the package that I'm inflicting on a lot of users. It takes care, but it has a value for me, so I take the time.
Thanks, Peter
-
anicka＠suse.cz -
Juergen Weigert -
Magnus Boman -
Pavol Rusnak -
Peter Poeml -
Richard Guenther -
Stephan Kulow -
Vincent Untz -
Vladimir Nadvornik