Re: changelog in spec file, was Re: Stop the git abuse

2012-05-31 Thread Nils Philippsen
On Sun, 2012-05-20 at 20:02 -0400, Paul Wouters wrote: On Fri, 18 May 2012, Richard W.M. Jones wrote: On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote: And definitvely, for me, (and probably only for me), git is really not a good tool for spec maintenance. Not duplicating

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-24 Thread Stanislav Ochotnicky
Quoting Paul Wouters (2012-05-21 02:02:23) On Fri, 18 May 2012, Richard W.M. Jones wrote: On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote: And definitvely, for me, (and probably only for me), git is really not a good tool for spec maintenance. Not duplicating the changelog

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-24 Thread Thomas Spura
On Thu, May 24, 2012 at 11:02 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote:  * If a git commit is tagged in a specific way, omit from rpm changelog.   What I mean by tagged is a git tag, in form of let's say   silentXXX. Where XXX has to be unique, but that can be figured out by  

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-24 Thread Jan-Frode Myklebust
On Thu, May 24, 2012 at 11:15:38AM +0200, Thomas Spura wrote: On Thu, May 24, 2012 at 11:02 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote:  * If a git commit is tagged in a specific way, omit from rpm changelog.   What I mean by tagged is a git tag, in form of let's say  

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-22 Thread Przemek Klosowski
On 05/20/2012 09:49 PM, Matthew Miller wrote: On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote: Agreed. changelog and version field conflicts are 90% of my cherry-pick conflicts. I would be in favour of no longer maintaining a changelog in the spec file As long as it gets put into

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-21 Thread Richard W.M. Jones
On Sun, May 20, 2012 at 09:49:03PM -0400, Matthew Miller wrote: On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote: Agreed. changelog and version field conflicts are 90% of my cherry-pick conflicts. I would be in favour of no longer maintaining a changelog in the spec file As

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-21 Thread Adam Williamson
On Mon, 2012-05-21 at 08:33 +0100, Richard W.M. Jones wrote: On Sun, May 20, 2012 at 09:49:03PM -0400, Matthew Miller wrote: On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote: Agreed. changelog and version field conflicts are 90% of my cherry-pick conflicts. I would be in

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-21 Thread Michael Scherer
Le lundi 21 mai 2012 à 09:01 -0700, Adam Williamson a écrit : On Mon, 2012-05-21 at 08:33 +0100, Richard W.M. Jones wrote: On Sun, May 20, 2012 at 09:49:03PM -0400, Matthew Miller wrote: On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote: Agreed. changelog and version field

changelog in spec file, was Re: Stop the git abuse

2012-05-20 Thread Paul Wouters
On Fri, 18 May 2012, Richard W.M. Jones wrote: On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote: And definitvely, for me, (and probably only for me), git is really not a good tool for spec maintenance. Not duplicating the changelog would help. There's little reason to have a

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-20 Thread Matthew Miller
On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote: Agreed. changelog and version field conflicts are 90% of my cherry-pick conflicts. I would be in favour of no longer maintaining a changelog in the spec file As long as it gets put into the final RPM in the build process somehow.

Re: changelog in spec file, was Re: Stop the git abuse

2012-05-20 Thread Tom Diehl
On Sun, 20 May 2012, Matthew Miller wrote: On Sun, May 20, 2012 at 08:02:23PM -0400, Paul Wouters wrote: Agreed. changelog and version field conflicts are 90% of my cherry-pick conflicts. I would be in favour of no longer maintaining a changelog in the spec file As long as it gets put into