Re: How to cope with patches sanely
On Sat, Feb 02, 2008 at 12:04:16PM +0000, Roger Leigh wrote:
> While the time might not be yet, DVCS systems are getting to the point
> where they could make our lives all much simpler. Having all of
> Debian in git, where anyone can clone and hack would be (IMHO) a
> worthy goal to aim for. Currently, there are many packages I can't
> work on--simply because I am not intimately familiar with the
> patch-system-du-jour the maintainer chose,
> upstream-tarball-in-orig.tar.gz being my greatest bane. Having a
> single tool we all need to learn once would (again, IMHO) be useful in
> fixing this.
While I'm a big fan of DVCS systems, and in fact use git all the time
--- including git to manage quilt seriess --- I don't think DVCS
systems would necessarily be right for Debian.
The reason for that is because in the long-run, we do want to get our
changes upstream, and not end up in a merge hell where Debian packages
have diverged significantly from upstream and merging changes back is
hard. The problem with DVCS tools is that they aren't necessarily
well suited for that. It's too easy for people to just hack a few
changes, then commit, then hack a few more changes, and commit, .etc.
You can use tools such as "git rebase --interactive" to fold related
patches and patches which fix bugs introduced in patches, but it's
complicated, and not something a beginner DVCS user would find easy.
If you force people to maintain patchsets, where each patch has a
description describing *what* change was made, and why, it's much,
MUCH more convenient for upstream to understand what you've done, and
And if people want to use git, it's possible using git to take set of
git comments and turn it into a patchset which is quilt-compatible.
But let that be up to each maintainer. Different maintainers can use
whatever tools they want, as long as the output format is a
quilt-style patchset. What's far more important is that maintainers
are strongly encouraged to maintain a high quality patchset which is
suitable for acceptance by upstream. Otherwise, as upstream keeps
moving, it will be harder and harder to forward patch our changes, and
that way lies some of the headaches which the Ubuntu project has been
facing (albeit for different reasons).