Web lists-archives.com

Re: Preferred git branch structure when upstream moves from tarballs to git

On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
> On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote:
> > As an example: to update to a new upstream release, I ideally just have
> > to drop the new upstream tarball, update d/changelog and am done.
> > Compare with [1] which is much more complicated, even ignoring the extra
> > complexity using dgit adds compared to just using git.
> > 
> >   [1] https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES
> As a package maintainer, if you don't keep the whole source package in
> git, you're giving up on a lot of the power of git.

I think keeping entry barriers low is more important than being able to
use all the power of Git.  That's sadly one of the main problems with
Dgit: it raises entry barriers by making packaging more complicated. 
Packaging shouldn't be complicated: it's just a build recipe plus some

> The most
> significant thing is that you cannot manipulate quilt patches as commits
> on a branch.  It is also much more involved to cherry pick commits from
> upstream branches, and quickly obtain diffs between Debian's version of
> the code and arbitrary other branches, to mention a few other things.

Most packages don't need that either: for me most changes are either
fairly static (no merge conflict) or are just backports of upstream
commits (in which case they can just be removed when using a new
upstream version).

It does get easier when most fixes are applied upstream instead of
staying only in Debian :-)

> I also think that you're doing a disservice to downstream users.  If
> you're trying to fix a bug in the packaged version of some software on
> your computer, you don't care about the distinction between Debian's
> packaging scripts and the upstream code.

Either the bug is in upstream code, then you just need the upstream
source (and the patch should be pushed upstream anyway).  Or it is in
the (ideally smalll) Debian-specific parts which hopefully don't need a
long history to understand.

If you have large, invasive changes from upstream, you effectively fork
the package.  Maybe one should release it as a "fork" then so non-
Debian distributions can benefit from the changes in the fork.  That is
arguable a disservice to users...