Re: Best practices for Debian developers who are also upstreams?
* Otto Kekäläinen:
> Is somebody else already doing something similar like this?
We are doing this with glibc in Fedora, which is not Debian, but kind
of similar. We try to push all backportable fixes to the upstream
release branches (and master) and synthesize new pseudo-release
tarballs from those branches. This means that (the equivalent of)
.orig.tar.xz reflects upstream contents, but necessarily an actual
release tarball.
This means that the set of downstream patches is reasonably small, and
grows only moderately due to ongoing bug-fixing. In some cases, we
want to backport things into Fedora which do not seem appropriate for
upstream, and those end up as patch files.
The distribution packaging bits do not live in the upstream
repository, but we have special (glibc-specific) scripts which allow
us to merge in upstream changes (using git cherrypick and git rebase),
so this mostly a matter of training people to use these scripts.
I think this approach is only possible because we have stable release
branches upstream where we can backport the things we are interested
in (and other contributors are reasonably conservative), and we are
willing to respin the tarballs. It simplifies matters for the
uploaders, but we cannot easily bisect individual changes/upstream
commits because they do not exist downstream, and the upstream
repository lacks the distribution customizations.
Reply to: