There have been a two long threads on the debian-devel mailing list
about the representation of the changes to upstream source code made
by Debian maintainers. Here are a few notes for my own reference.
I spent a lot of time defending the workflow I described in
dgit-maint-merge(7) (which was inspired by this blog post).
However, I came to be convinced that there is a case for a manually
curated series of patches for certain classes of package. It will
depend on how upstream uses git (rebasing or merging) and on whether
the Debian delta from upstream is significant and/or long-standing. I
still think that we should be using dgit-maint-merge(7) for leaf or
near-leaf packages, because it saves so much volunteer time that can
be better spent on other things.
When upstream does use a merging workflow, one advantage of the
dgit-maint-merge(7) workflow is that Debian’s packaging is just
another branch of development.
Now consider packages where we do want a manually curated patch
series. It is very hard to represent such a series in git. The only
natural way to do it is to continually rebase the patch series against
an upstream branch, but public branches that get rebased are not a
good idea. The solution that many people have adopted is to represent
their patch series as a folder full of .diff files, and then use
gbp pq to convert this into a rebasing branch. This branch is not
shared. It is edited, rebased, and then converted back to the folder
of .diff files, the changes to which are then committed to git.
One of the advantages of dgit is that there now exists an official,
non-rebasing git history of uploads to the archive.
It would be nice if we could represent curated patch series as
branches in the dgit repos, rather than as folders full of .diff
files. But as I just described, this is very hard. However, Ian
Jackson has the beginnings of a workflow that just might
fit the bill.
This is a well-written biographical piece on Stallman.