[opensuse-packaging] Re: content of change log (Re: [obs submit-request 176782] devel:languages:python/python-ldap: declined by saschpe)
Hi Michael, CC'ing opensuse-packaging@ On 05/28/2013 10:00 AM, Michael Ströder wrote:
HI!
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.
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.
Where is this dicussed in detail?
I think this was discussed in many ways on opensuse-package@ and probably opensuse-factory@. Please check the archives, we may want to enhance the wiki either way.
Ciao, Michael.
SPeilicke@suse.com wrote:
State of submit-request #176782 was changed by saschpe:
new -> declined
Comment: sorry but you have to provide a more detailed changes entry when updating versions. otherwise this won't enter factory
https://build.opensuse.org/request/diff/176782
Source project: home:stroeder:branches:devel:languages:python package: python-ldap revision: 5
Target: project: devel:languages:python package: python-ldap
-- 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
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.
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 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! Ciao, Michael.
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
On Tue, May 28, 2013 at 7:01 AM, Sascha Peilicke <speilicke@suse.com> wrote:
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"?
Real question one should be asking, is how is a *tool* supposed to know? Because, missing manpower aside, YaST *should* be showing those upfront. So it's a matter of making it machine-findable (efficiently), besides human-readable. OSC *should* be able to point to a changelog relevant to a new build failure. It's non-trivial, but it'd be possible, *iff* the changelog was machine-findable. And machine-findable is as easy as making it standard. NEWS or CHANGES inside the RPM isn't (and IMHO can't reliably be) standard. Only the spec's changelog is. The changelog can point to a file inside the RPM. And that'd be machine-findable enough. And osc is python... um... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, May 28, 2013 at 11:29:43AM +0200, Michael Ströder wrote:
Sorry, but a packager is often not able to judge which details are important and which are not.
Uh, if you don't have a clue about a package you probably should not be the packager for it. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Schroeder wrote:
On Tue, May 28, 2013 at 11:29:43AM +0200, Michael Ströder wrote:
Sorry, but a packager is often not able to judge which details are important and which are not.
Uh, if you don't have a clue about a package you probably should not be the packager for it.
Uh, and you're feeling very smart with your answer. In this particular case (python-ldap) I'm the main upstream developer *and* update the package from upstream. For other Python modules (e.g. pyasn1 and pyasn1-modules) I'm just interested in getting more recent releases because they contain bug fixes. But I cannot overlook *all* consequences and side effects of upgrades. So if you insist on a more verbose changelog the only reasonable option is to simply copy&paste the whole upstream changelog in the package's changelog. Also note that I'm not a openSUSE developer. I'm just contributing package updates as a side job. I have many other things to do and I will simply stop re-submitting branched packages. Ciao, Michael.
On Tue, May 28, 2013 at 12:17:50PM +0200, Michael Ströder wrote:
For other Python modules (e.g. pyasn1 and pyasn1-modules) I'm just interested in getting more recent releases because they contain bug fixes. But I cannot overlook *all* consequences and side effects of upgrades.
Nobody asks you to know all consequences, but you should be able to judge from the upstream changelog what's intersting to an end user and what's not. If you don't feel able to do that, don't do the update. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Schroeder wrote:
On Tue, May 28, 2013 at 12:17:50PM +0200, Michael Ströder wrote:
For other Python modules (e.g. pyasn1 and pyasn1-modules) I'm just interested in getting more recent releases because they contain bug fixes. But I cannot overlook *all* consequences and side effects of upgrades.
Nobody asks you to know all consequences, but you should be able to judge from the upstream changelog what's intersting to an end user and what's not.
"End user" is pretty blurry in case of a lib or module, so is the term "interesting". IMO the amount of information in your statement above is zero.
If you don't feel able to do that, don't do the update.
Ok, I won't submit packages anymore and only do what I personally need. Ciao, Michael.
participants (4)
-
Claudio Freire -
Michael Schroeder -
Michael Ströder -
Sascha Peilicke