Re: RFC: DEP-14: Recommended layout for Git packaging repositories
Hi Raphael,
On Thu, Nov 13, 2014 at 09:46:13AM +0100, Raphael Hertzog wrote:
[..snip..]
> Problem 1: the derivatives
> --------------------------
>
> So I am a Kali Linux contributor. We use git repos to maintain all our
> packages and we use git-buildpackage. Most of the Kali contributors
> are not long-term Debian contributors, I write documentation so that
> they can contribute to Kali (while basing our work on Debian).
>
> To make this manageable I opted to always use a workflow based on
> "git-import-orig". Even when Debian has its own git repo, we start
> from the released source packages because that's the only level of
> uniformity that we can rely on. And it's a pity because if we could
> build on Debian's git repo, it also means that our work would be easier
> to merge for the Debian maintainer. They could add the Kali repo as a
> remote (without fearing any conflict in terms of tags, branch names)
> and just merge or cherry-pick as appropriate.
I don't think Kali is on it's own here. The above workflow was the
first major use case I saw gbp being used at a couple of years ago. We
had contributors with different skill sets that needed to modify
various packages building a (private) downstream. Having a standardized
work flow for modifying and building packages helped a lot.
Being based on stable, changes we contributed back stayed in our tree
for a long time until the next Debian stable release. Other changes
needed to be kept forever. We didn't want to get into every VCS Debian
used (and by far not all packages were in a VCS at that time) and use
the powers of git to track patches, rebase, etc.
Therefore I see a lot of value having a common namespace / branch
layout for Debian as well as downstream branches and tags. This
allows us to easily track the modifications.
Cheers,
-- Guido
Reply to: