[Pkg-clamav-devel] Preparing for 0.94.1

[Michael Tautschnig]

> This one time, at band camp, Michael Tautschnig said:
> > Hi all,
> > 
> > I was just trying to find out what to do to prepare a release of 0.94.1. I don't
> > yet feel too comfortable with the workflow, so just let me try to sketch it
> > here:
> > 
> > - Get a git remote ref to ssh://git.debian.org/git/users/sgran/clamav-devel
> > - Do git merge clamav-devel/tags/clamav-0.94.1 (actually it seems that this one
> >   doesn't exist in the clamav-devel git repository yet!?)
> 
> The tags don't usually appear in their svn tree for at least several
> hours after release.  I've spoken with upstream, and they have promised
> to address it more quickly in future (read, hopefully this one)
> releases.
> 

Hmm, the commit is like 4-5 days ago, so this shouldn't be the case, right? Seen
here:

http://svn.clamav.net/websvn/listing.php?repname=clamav-devel&path=%2Ftags%2Fclamav-0.94.1%2F&rev=4318&sc=1

> > - Download upstream's tarball and verify that everything had actually made its
> >   way into their subversion repository
> > - The usual round of BTS checks (actually, in this case, also looking into the
> >   staged version of rc1 in git is worthwhile)
> > - Anything else? pristine-tar and etch-volatile may need work; what actually is
> >   pristine-tar good for? Should we try to get this release into etch-volatile?
> 
> pristine-tar stores an xdelta for the tarball in the repo against a git
> checkin.  What this means in practical terms is that, in exchange for
> the 14k or so of xdelta storage, you get to keep the tarball in git.
> This means everyone gets access to it quickly instead of having to also
> download the tarball in addition to the git repo.  Joey Hess is truly a
> god among men.
> 
Could you detail the actual workflow to get the pristine-tar stuff into the
repository? I've never used pristine-tar before, so please bare with me...

> Yes, I think targetting etch-volatile is a good idea as well - certainly
> most people using clamav on stable in any serious way are using it from
> volatile, judging by the bug reports.
> 
Should one just do the same merge command as noted above and apply it in an
etch-volatile checkout?

> I think that overall, you have outlined the important parts of the
> workflow.  The few things missed out are things like checking for new
> config options (I'm fairly sure one has been introduced this time, but
> debian/rules should FTBFS rather than let a new one slip by - the main
> problem is when an option is dropped, it's harder to catch without
> upgrade testing).  Also, I usually run icheck over the old libclamav.h
> and the new to make sure no major changes have slipped in without
> appropriate changes to the packaging - Debian has caught at least one
> accidental soname change that was necessary that upstream missed.
> 
In what way does a new config option cause an FTBFS? About the icheck stuff:
I've never used that one either, but I guess that I'll find out how to do it :-)

Thanks for your help and guidance,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-clamav-devel/attachments/20081104/ccfc9437/attachment.pgp