On Friday, November 04, 2016 10:47:32 AM Barry Warsaw wrote: > On Nov 03, 2016, at 08:36 PM, Julien Muchembled wrote: > >I'm used to gbp. I don't know git-dpm (or I forgot after seeing I would not > >like?) > > git-dpm is usually pretty easy, but it's really only used in a few cases, > such as importing a new upstream, managing the patch stack, and tagging. > We document the team's use cases pretty well so you don't even really have > to remember much: > > https://wiki.debian.org/Python/GitPackaging#New_upstream_release > > For a lot of other package management tasks (e.g. building source packages, > cloning, pulling, etc.), gbp works just fine. > > That said, we know git-dpm has not been developed in a very long time, and > is for all intents and purposes, abandonware. It works, so I don't think > there's a huge urgency to get rid of it (obviously, since we haven't ;) but > it should be in our long-term team goals to move away from it. > > >Not sure if all python-modules repositories are like persistent, but for > >me, mixing Debian work with imported tarballs in the same branch is > >terrible. When possible, I prefer to fork the upstream repository, > >otherwise no upstream source at all. > > You're not alone, but I think that's still a minority opinion in the team. > Our packages are so tightly integrated with PyPI, and source tarballs are > such an ingrained aspect of that service, that a pristine-tar based > approach for team packages still makes sense, IMHO.
You can integrate a new upstream directly from an upstream git repository with git-dpm if that's what makes sense for a particular upstream. Scott K
