From: Petr Baudis <pasky@ucw.cz>
Date: Tue, 03 May 2005 21:21:43 GMT
Subject: Re: [PATCH 0/3] cogito spec file updates
Message-ID: <20050503212142.GB15995@pasky.ji.cz>
In-Reply-To: <20050503193536.GE5324@shell0.pdx.osdl.net>

Dear diary, on Tue, May 03, 2005 at 09:35:36PM CEST, I got a letter
where Chris Wright <chrisw@osdl.org> told me that...
> * Chris Wright (chrisw@osdl.org) wrote:
> > Here's the outstanding updates for the spec file, up to 0.8-2 which is
> > the latest on kernel.org.
> > 
> > 	http://www.kernel.org/pub/software/scm/cogito/RPMS/
> 
> What's your method for creating a release tarball?  If it were formalized
> (i.e. Makefile rule), then it'd be simple to use VERSION to drive the
> spec file, and it'd only need updating for real content changes (similar
> to what Kay did).

For now, I do it so seldom that I just manually do

	cg-log >Changelog
	cg-export ~/cogito-0.9
	cp Changelog ~/cogito-0.9
	cd ~
	tar cvvfz cogito-0.9.tar.gz cogito-0.9

OTOH, I'd like to change this all to just

	cg-export ~/cogito-0.9.tar.gz

when I get to merge the relevant patches; I'm not sure there is so much
of a value to bundle the Changelog; just get the git tree and do cg-log
on your own, or use the web interface.

I might however have some private mkrelease.sh script which would do

	echo "$1" >VERSION
	update-spec-file
	echo "$1" | cg-commit
	cg-tag "$1"

or something.


BTW, did you have a particular reason to split the .spec file updates to
three parts? I think it doesn't make much sense and it'd be probably
enough to update it at once, when we are not doing it at the right time
anyway.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor