Le mercredi 25 février 2009, à 18:13 +0100, email@example.com 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)