On Wed, Dec 20, 2006 at 10:28:07PM -0500, David Nusinow wrote:
> On Wed, Dec 20, 2006 at 01:02:45PM +0100, Thierry Reding wrote:
> > * Otavio Salvador wrote:
> > > That means we'll stop to use the quilt to manage the patches and leave
> > > git to manage all delta between Debian and original upstream code?
> >
> > That is still something that's up for discussion. I think stgit was being
> > considered as an alternative to quilt for managing the Debian-specific
> > patches. As I understand it, it's pretty much the same as quilt only it's
> > using git as backend.
>
> When we last had this discussion[0], everyone was in favor of keeping the
> quilt system. No one really spoke up in favor of stgit, although it was
> listed as an option. Given that discussion, and a currently working patch
> system with quilt, I think we should keep using quilt.
>
> - David Nusinow
>
> [0] http://lists.debian.org/debian-x/2006/08/msg00110.html
Looking at this again, let's do a more serious analysis before making rash
decisions.
The benefits of quilt:
1) We already know it works and works well. We've had no problems related
to quilt since we adopted it. stgit is an unknown at this point.
2) We already have both our own and the quilt package's makefile stuff
written
3) Because of (2) we can easily customize it to fit our needs. This allows
things like patch-audit (I'm not sure if stgit can be customized this
easily. Does anyone else know?)
4) quilt has become more popular, and so it's generally well known to the
general developer population
5) Each patch is a file, which makes it very easy to extract them for
things like emailing them. It's also trivial to see which patches we
apply simply by looking at git.debian.org
6) quilt is somewhat transparent because of this. Anyone can look in
debian/patches and see what we're applying. They have to know that this
exists though.
Now the benefits of stgit:
1) Integrates very nicely with git. Having it as an extension to the git
interface is really lovely.
2) Probably more transparent to upstream or other people less familiar
with Debian packaging. Just tell them that debian-specific patches are
in stgit, and they already know the interface to use it.
3) Working with it day to day will probably be a lot easier than using
quilt. quilt requires you to set an environment variable to tell it
where the patches directory is, and so forth, or use the symlink scheme
like we currently have. stgit just works.
4) The .diff.gz becomes easier to read. Rather than looking at diffs of
diffs like the current scheme, you just look at a diff.
5) No makefile stuff! We'll probably have to adapt git-buildpackage to
automagically push all the patches before building, but this should be
trivial.
6) Integrates very nicely with qgit (though not gitk yet).
It's a tough choice. The ease of use of stgit sounds really nice to me, but
I also love the transparency that having the patches in a location like
debian/patches affords us. I'm not horribly worried about that though, but
it is a real benefit. We can get around that by artificially exporting all
the patches to debian/patches. It's more work, although I'd be happy to
write a simple script to do this. My feeling is that this would be the best
of both worlds. What do you guys think?
- David Nusinow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
