[Pkg-clamav-devel] Hi everybody

[Stephen Gran]

This one time, at band camp, Scott Kitterman said:
> On Sat, 23 Aug 2008 15:18:51 +0100 Stephen Gran <sgran at debian.org> wrote:
> ...
> >I think the next thing to do is to have a nice flamewar^Wdiscussion
> >about what VCS to use :)
> >
> >I have used a variety of things over the years, from release-based
> >directories on disk to svn, now git.  I'm happy to use almost anything
> >(for a version of 'almost anything' that does not include bzr :), but I
> >am personally happiest with git at the moment.
> >
> >I have a git-svn setup to track upstream, and I have a git repo for the
> >debian work.  It's quite likely that it could use some reorganization,
> >since I set it up as I was learning git, and there's probably several
> >pieces of it that could be done better.
> 
> I think before we pick a VCS, I'd suggest discussing the VCS style.  Should 
> it be a debian dir only packaging VCS and stil use a patch system or a repo 
> carrying the full upstream source and the packaging with changes to 
> upstream code managed in the VCS?

That's a good point.  I've used combinations of all those systems at
various points, and I have to say I'm happiest having everything in the
VCS, including tarballs (now that joeyh has written pristine-tar, it's
not even particularly wasteful to keep them there).  Otherwise I always
feel like I have to remember which hoops to jump through to just build
the package, which seems like wasted effort each time.  That being said,
I'm not opposed to other systems - I just don't enjoy them as much.

There are advantages and disadvantages to patch systems on top of a VCS.
For other people doing an NMU or a security (not that we'll need that
since we have a team now :) a patch system makes for slightly more work
if they are changing upstream code.  On the other hand, keeping all the
changes in the VCS means that if someone does an NMU, we have to import
their patch into the VCS at some point.

I recently converted from using dpatch to just keeping the changes in
the VCS, for what that's worth - I'm happy to go back if that's what
people decide, though.

> My concern is that since this upstream does not have a good track record of 
> having what's in their svn match what they put in their tarball we really 
> can't rely on pulls from their svn.

We can't completely, it's true.  What I've been doing so far is diffing
the tarball and the branch, and applying an incremental patch if needed
to make them match, then rolling back the patch before the next pull.
This is not always needed, and mostly seems to affect the docs tree
(maybe they rebuild the html and so on and forget to check it in?).  The
advantage of working with their svn is that for stable security
backports of code changes, it can make it quite a bit easier to isolate
which set of changes matter - not that they always apply cleanly, but
when they do, `git cherry-pick $rev; dch -i; git commit` is a nice
workflow.

Cheers,
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran at debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-clamav-devel/attachments/20080824/c22072a9/attachment.pgp