On 05/28/2013 11:29 AM, Michael Ströder wrote:
Sascha Peilicke wrote:
CC'ing opensuse-packaging@
On 05/28/2013 10:00 AM, Michael Ströder wrote:
I think in the case of a simple update due to a new upstream release, especially with a module used by developers, it's the most appropriate change note to just reference exact release number of the new upstream version.
The following two approaches are IMO completely wrong:
1. Copy&paste the whole possibly lengthy change log of upstream.
Sure, but the more important details should be added.
2. Summarize the change log of upstream release likely leading to incomplete and therefore useless information.
It's anything but useless, especially if there's a potential behavior change.
Sorry, but a packager is often not able to judge which details are important and which are not. So it boils down to: 1. copy&paste the whole possibly lengthy change log of upstream.
How is a end-user supposed to judge then? The changes file is meant to be his primary source of information.
The changelog of a package IMO should only mention
1. local patches, backports etc. (most important)
2. changes to spec files, package build options etc.
3. One-line notes about relationship to upstream release.
4. Known side effects on other packages.
Agreed on all of those :-)
5. In rare cases changes of upstream code in case upstream code does not provide a detailed change log.
So you really want people to first download the RPM, unrpm it and then search for a ChangeLog or CHANGES or NEWS file? I think it is better to allow users to use the same process they already know, namely "rpm -q --changelog $foo.rpm" and get something meaningful.
I don't see the real difference. In case of package python-ldap the CHANGES file is installed here: /usr/share/doc/packages/python-ldap/CHANGES
Right, and in another package's case the file may be elsewhere and named differently or even lacking. How am I supposed to know that? Am I supposed to guess "Ah, there's no suitable changes entry, maybe I should go look for CHANGES/NEWS/ChangeLog/changelog or even NEWS.txt"?
Especially when using a 3rd-party Python module I will never ever rely on platform-specific output of rpm -q --changelog to learn about changes in the upstream module. Upstram changelog is always the only authoritative information source! If you're a developer looking at anything else summed up by 3rd party is really stupid!
I agree we're not yet where Debian is when it comes to that. And yes, only upstream is authorative but that's not the point here. A developer will never look at a package changelog, he uses git or whatnot as a more appropriate tool. A packager isn't interested in that upstream changelog either. A user is since it's his only source of judgement if he actually wants the package update or not. Since there was no real consent in the past, I'll draw the project maintainer card. If you want to get your stuff into devel:languages:python, you should follow the Factory packaging guidelines. That includes properly summarizing version updates. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org